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

Yup.
-=R
On Dec 12, 2013 3:58 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

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