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

Martin said:

> 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.


That's true, *if* clients implement the http2-tls protocol identifier semantics uniformly; otherwise, they won't know whether they need to offer a valid certificate to upgrade to that protocol. 

When I wrote this draft, there was still active debate; some people thought opp encryption without authentication could be useful, whereas others are firm that this is not a good direction, and opp encryption should only happen when coupled with strong server auth.

If we overload the semantics of http2-tls (ignoring the exact syntax of the identifier) to mean "opportunistic encryption without authentication", but some browsers require authentication, we have an interop problem, and opp encryption without authentication is effectively impossible to use. 

Now, if no one is interested in using TLS with authentication for http:// URIs, this problem (probably) goes away. The one thing that worries me a tiny bit is that a browser's position about what an acceptable mix of security characteristics might change over time, and if it does, we may need this distinction again. However, since we're using draft identifiers, it's not a huge risk.

Based on this discussion, it sounds like I can go ahead and remove h2r and refine the semantics of h2t to include the HTTP URI use case (i.e., no auth if on the same host, strong auth if on a different host). 

Make sense?

Cheers,



On 13 Dec 2013, at 5: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/
> 
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 12 December 2013 23:57:11 UTC