W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 12 Dec 2013 20:21:36 +0000
To: William Chan (陈智昌) <willchan@chromium.org>, "Patrick McManus" <mcmanus@ducksong.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>, "Mark Nottingham" <mnot@mnot.net>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <emac540e4f-ad51-4150-8748-5daacd186421@bodybag>
Maybe the problem is us.

e.g. that we think the level of https adoption is a problem to be 
solved.

personally I do not.

What if it simply reflects the desires of the people who own and run the 
sites. Exercising their choice.

We are proposing (yet again) taking that choice away which I have a 
major problem with.  It's a philosophical problem, I don't believe any 
of us have the right to make those choices for everyone else, especially 
considering (which few seem to be) the ENORMOUS cost.

Adrien

------ Original Message ------
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: "Patrick McManus" <mcmanus@ducksong.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>; "Mark Nottingham" 
<mnot@mnot.net>; "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 13/12/2013 09:05:07
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>Me speaking as a Chromium project representative here:
>We talked about this internally amongst Chromium project members, and
>the *current consensus* opinion is that Chromium does not support
>opportunistic encryption, nor would we implement it were such a
>mechanism standardized (I'm assuming no one's proposing mandatory to
>implement...the draft does not appear to do so). We want to push
>people toward adopting HTTPS, not the middle ground of opportunistic
>encryption. You can see some opinions from other project members
>(https://twitter.com/sleevi_/status/410092604613611520,
>https://twitter.com/justinschuh/status/410104482622472192,
>https://twitter.com/sleevi_/status/410093372116709376).
>
>OK, back to me talking as me, just another IETF individual:
>I respect the goals behind opportunistic encryption, but it is
>*unclear* to me if it is actually a net positive. There are definitely
>a lot of things to like about it which I think have already been
>covered. But I'm concerned that the risk of hurting HTTPS adoption is
>real and significant. I don't have hard data to back this up. But even
>looking at the numerous complaints about browser warnings for
>self-signed certs
>(http://robert.accettura.com/blog/2008/07/19/unobstructed-https/,
>http://it.slashdot.org/story/08/06/24/2345223/when-is-a-self-signed-ssl-certificate-acceptable,
>etc) is indicative that site developers perceive a lot of benefit from
>encryption without authentication. I am not convinced site developers
>sufficiently understand the importance of authentication, and I worry
>that offering a middle ground of unauthenticated encryption will give
>them an out to not go full HTTPS.
>
>I think that the main problem we'd like to address is that HTTPS
>adoption sucks. I join others in saying we should focus our energies
>on solving that problem
>(https://twitter.com/BRIAN_____/status/410181992085336064), rather
>than working on proposals where the net result is unclear to be
>beneficial or detrimental.
>
>Cheers.
>
>On Thu, Dec 12, 2013 at 10:03 AM, Patrick McManus 
><mcmanus@ducksong.com> wrote:
>>  I am slowing coming to a similar position on http2-encryption that 
>>Martin
>>  expresses in the quote trail.
>>
>>  Doing the relaxed semantic is imo probably a net-positive. I'm not 
>>entirely
>>  convinced but I'm not sure anything other than time and operational
>>  experience could make it more clear. (anyone interested in a poc 
>>please let
>>  me know.)
>>
>>  I also don't see a need to use a different *PN token for it than you 
>>would
>>  for normal https. Any advertisement for relaxed (e.g. via alt-svc) is 
>>scoped
>>  to the origin (and therefore scheme) and http/2 itself carries a 
>>scheme on
>>  every transaction so the server isn't gaining any new information by 
>>putting
>>  a relaxed token in the handshake. Brian, over in TLS WG, and Martin 
>>have
>>  made different arguments why using 2 identifiers could be a net loss 
>>to
>>  security and I don't see anyone arguing its necessity.
>>
>>
>>  On Thu, Dec 12, 2013 at 12:31 AM, Martin Thomson 
>><martin.thomson@gmail.com>
>>  wrote:
>>>
>>>  Overall, I think that the relaxed semantic proposed here is a 
>>>pragmatic
>>>  approach to getting more goodness into our protocol. Goodness being, 
>>>in this
>>>  instance, better resilience against passive attacks, as well as 
>>>opening
>>>  avenues to some forms of active attack mitigation.
>>>
>>>  Re C.4:
>>>
>>>  I haven't seen strong justification for the "h2r" identifier. On the
>>>  contrary, I see potential for harm in it. I'm worried that this will 
>>>create
>>>  more confusion about the security properties of the protocol.
>>>
>>>  The idea that "h2r" might be used as some form of signal is 
>>>basically
>>>  devoid of value unless you believe that http: URIs will somehow need 
>>>to be
>>>  retrieved with the same level of confidentiality and authentication 
>>>as
>>>  https: ones. I just don't see a server that cares about this leaving 
>>>the "s"
>>>  off.
>>>
>>>  I believe it to be sufficient for the client to just use TLS. Any
>>>  decisions about authentication are largely up to the client. The 
>>>server
>>>  would have to assume that http: URIs aren't going through rigorous 
>>>checks,
>>>  though that doesn't mean that checking is completely precluded. I 
>>>can
>>>  imagine not checking in the classic CA chaining sense, but maybe 
>>>CT-like
>>>  mechanisms could be useful in reducing the incidences of some types 
>>>of
>>>  active attacks. Especially if we are able to provide sufficient 
>>>incentive
>>>  for proxies to come out from cover of darkness (actually, that may 
>>>be a
>>>  necessary precondition for some really strong improvements).
>>>
>>>  Creating disincentives around the use of "better" modes is - aside 
>>>from
>>>  just being perverse - ultimately going to be self-defeating. As long 
>>>as the
>>>  downgrade path includes HTTP/1.1 in the clear, an active attack is 
>>>going to
>>>  be trivial to mount without some other facilities in place.
>>>
>>>  I think that a "relaxed" mode is a good incremental improvement. 
>>>Maybe it
>>>  will be a leg up on those facilities.
>>>
>>>  On Dec 10, 2013 8:21 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>>>>
>>>>  FYI.
>>>>
>>>>
>>>>  Begin forwarded message:
>>>>
>>>>  > From: internet-drafts@ietf.org
>>>>  > Subject: New Version Notification for
>>>>  > draft-nottingham-http2-encryption-02.txt
>>>>  > Date: 11 December 2013 3:18:55 pm AEDT
>>>>  > To: Mark Nottingham <mnot@mnot.net>
>>>>  >
>>>>  >
>>>>  > A new version of I-D, draft-nottingham-http2-encryption-02.txt
>>>>  > has been successfully submitted by Mark Nottingham and posted to 
>>>>the
>>>>  > IETF repository.
>>>>  >
>>>>  > Filename: draft-nottingham-http2-encryption
>>>>  > Revision: 02
>>>>  > Title: Opportunistic Encryption for HTTP URIs
>>>>  > Creation date: 2013-12-11
>>>>  > Group: Individual Submission
>>>>  > Number of pages: 10
>>>>  > URL:
>>>>  > 
>>>>http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-02.txt
>>>>  > Status:
>>>>  > http://datatracker.ietf.org/doc/draft-nottingham-http2-encryption
>>>>  > Htmlized:
>>>>  > http://tools.ietf.org/html/draft-nottingham-http2-encryption-02
>>>>  > Diff:
>>>>  > 
>>>>http://www.ietf.org/rfcdiff?url2=draft-nottingham-http2-encryption-02
>>>>  >
>>>>  > Abstract:
>>>>  > This document proposes two changes to HTTP/2.0; first, it 
>>>>suggests
>>>>  > using ALPN Protocol Identifies to identify the specific stack of
>>>>  > protocols in use, including TLS, and second, it proposes a way to
>>>>  > opportunistically encrypt HTTP/2.0 using TLS for HTTP URIs.
>>>>  >
>>>>  >
>>>>  >
>>>>  >
>>>>  > Please note that it may take a couple of minutes from the time of
>>>>  > submission
>>>>  > until the htmlized version and diff are available at 
>>>>tools.ietf.org.
>>>>  >
>>>>  > The IETF Secretariat
>>>>  >
>>>>
>>>>  --
>>>>  Mark Nottingham http://www.mnot.net/
>>>>
>>>>
>>>>
>>>>
>>
>
Received on Thursday, 12 December 2013 20:21:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC