W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 11 Dec 2013 21:31:58 -0800
Message-ID: <CABkgnnULeMTH4HEUx9bm80k+4HD64ZNHEFkkLXG2qU_PTgK4+g@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 05:32:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC