- From: 陈智昌 <willchan@chromium.org>
- Date: Thu, 12 Dec 2013 15:45:46 -0800
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Dec 12, 2013 at 3:25 PM, Adrien de Croy <adrien@qbik.com> wrote: > > > ------ Original Message ------ > From: "William Chan (陈智昌)" <willchan@chromium.org> >> >> Oh, I misunderstood you and perhaps miscommunicated. Indeed, the >> >> Chromium project currently has no plans to respect a server >> advertisement that we could do unauthenticated TLS for http:// URIs. I >> believe the draft does not require a client to respect any such server >> advertisement, but merely proposes a mechanism for such a server >> advertisement. The site author has the choice to advertise >> unauthenticated TLS for http:// URIs, and the client has a choice of >> whether or not to respect it, and intermediaries have the choice of >> stripping out such advertisements if they so choose. I'm stating the >> current Chromium project stance is that we do not believe such a >> mechanism should even be standardized, and were it to be standardized, >> we would not respect the server advertisement in our browser. >> >> And for clarity, we do have a similar mechanism today in >> Alternate-Protocol. That is intended to allow site authors to >> advertise support for SPDY (or QUIC) for deployment of protocols with >> better networking performance, *not* for security or privacy. There is >> a fine line there, and it's definitely debatable whether or not we >> should even support Alternate-Protocol given possible confusion here. >> It's something we have in the back of our minds, but we have not felt >> a need to revisit it at this time. But we may need to do so. >> >> I hope this clarifies matters. Let me know if there is any confusion >> here. I understand that we seem to disagree both on: >> * Whether or not increased HTTPS adoption is a good thing > > I prefer to take 1 step back from there. > > Whether or not we should be trying to make a judgement call on whether > increased (or existing) level of HTTPS adoption is a good thing or not. > > I would propose we should not even be trying to rule on this point. > > >> * Whether or not opportunistic encryption should even be offered (by >> any party, be it server/intermediary, or client). > > I may be misunderstanding what is proposed. > > in mail, opportunistic encryption closest corollary is STARTTLS. In this > case, it's not unauthenticated. Also, the protocol isn't first layered over > TLS. the TLS is decided on later in the protocol, and if chosen, it is > added under the application layer over the transport layer. > > Is the current proposal that http2 always be over TLS but that there be an > optional opt-out for crypto? Or opt-out of the authentication part of the > crypto? I think you should read the draft, and in particular, http://tools.ietf.org/html/draft-nottingham-http2-encryption-02#section-2.1. It provides for a "h2r" (HTTP/2 relaxed) that does opportunistic unauthenticated encryption: """ When connecting to an "h2r" service, the algorithm for authenticating the server described in [RFC2818] Section 3.1 changes; the client does not necessarily validate its certificate for expiry, hostname match or relationship to a known certificate authority (as it would with "normal" HTTPS). """ So, it lets servers advertise support for serving http:// URIs over TLS, but without server authentication. The reason for doing so is to lower the barrier to using encryption, by not requiring server authentication, without having to switch URIs from http:// to https://. There is nothing in the proposal that requires that HTTP/2 always be over TLS. This is covered in the appendix (http://tools.ietf.org/html/draft-nottingham-http2-encryption-02#appendix-C.1): """ C.1. Will this make encryption mandatory in HTTP/2.0? Not in the sense that this proposal would have it required (with a MUST) in the specification. What might happen, however, is that some browser implementers will take the flexibility that this approach grants and decide to not negotiate for HTTP/2.0 without one of the encryption profiles. That means that servers would need to implement one of the encryption- enabling profiles to interoperate using HTTP/2.0 for HTTP URIs. Not in the sense that this proposal would have it required (with a MUST) in the specification. """ > > This leaves the TLS framing (and the problematic handshake) in each > connection, which I have a problem with purely from a performance POV. > > I'm in New Zealand so maybe I'm more sensitive to latency. It's at least > 200ms RT to the US from here. > > Regards > > Adrien > > >> >>> >>> Adrien >>> >>> >>>> >>>>> >>>>> 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 23:46:13 UTC