- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 12 Dec 2013 23:25:06 +0000
- To: William Chan (陈智昌) <willchan@chromium.org>
- 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>
------ 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? 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:25:12 UTC