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:05:34 UTC