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

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