Re: impact of 9.2.2 changes and discussions on opportunistic encryption draft

This is exactly where I wonder if there is going to be an interop issue due
to different
implementation plans.  For https-scheme traffic this is a non-issue
(it MUST be over authenticated TLS, of course, per section 4.).
For http-scheme traffic, there are a few different things that a client
could
do (per section 3) in response to receiving this over cleartext on port 80:

     Alt-Svc: h2=":443"; ma=3600

Clients can either:

1) Ignore the header and continue using cleartext HTTP/1.1

2) Connect to port 443 over TLS with ALPN "h2", *ignore* TLS certificate
    mismatches, and issue ":scheme=http" requests over HTTP/2.
    This is the initial draft-ietf-httpbis-http2-encryption behavior.

3) Connect to port 443 over TLS with ALPN "h2", *enforce* TLS certificate
    authentication, and issue ":scheme=http" requests over HTTP/2.
    If the TLS certificate mismatches, the client could either hard-fail
    or fallback to HTTP/1.1 over cleartext.

Per draft-ietf-httpbis-http2-encryption, if an HTTP-TLS header has been
returned in #2 and is cached then #3 should be enforced.

If everyone sticks with #1 or #2 and only uses #3 for the HTTP-TLS case
we're fine.  The problem becomes if any clients implement #3 without also
allowing #2.  In that case, we have no way for servers to ever safely
implement #2 (invalid TLS certificate for http scheme HTTP/2 over
unauthenticated opportunistic encryption).

It is unclear from the drafts (and from talking to some implementers)
that there is clarity here.  If we want it be possible to use
draft-ietf-httpbis-http2-encryption for http scheme URIs as described
in Section 3 of that draft, then there must be some signalling mechanism
that prevents interop issues.  The HTTP-TLS header field doesn't seem
to help here from an interop perspective, it only helps prevent fallback
from #3 to #1 or #2.

          Erik




On Fri, Oct 31, 2014 at 1:26 PM, Michaela LaVan <mlavan@google.com> wrote:

> As Rob has pointed out, this would represent a huge security regression
> for the spec. This change falls into the "can't live with it" category for
> us.
>
> On Thu, Oct 30, 2014 at 10:35 PM, Robert Collins <
> robertc@robertcollins.net> wrote:
>
>> On 31 October 2014 12:40, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>> > On 30 October 2014 15:36, Erik Nygren <erik@nygren.org> wrote:
>> >> In light of the discussion around 9.2.2, are there changes we want to
>> >> consider
>> >> making to draft-ietf-httpbis-http2-encryption that could improve
>> >> interoperability
>> >> when it is used?  Should that draft strongly encourage using TLS with
>> >> DHE/ECDHE key exchange for (P)FS, or does that dive too deeply into
>> >> the same problems with 9.2.2?
>> >
>> > We can tighten up the requirements, certainly.
>> >
>> >> One thought that I had was that we may want the localhost Alt-Svc to
>> >> indicate
>> >> when the server does not plan to offer valid authentication.
>> >
>> > This was a feature that was included in early versions, in a slightly
>> > different form.  And I have argued against it.  I don't see any value
>> > in this.  You either expect to authenticate, or not.  The way that the
>> > current draft addresses this is to have the new connection promise to
>> > provide authentication.  I'd rather not have two mechanisms for the
>> > same thing.
>>
>> Also wouldn't it deliver a trivial downgrade attack to folk who can
>> intercept and alter traffic?
>>
>> -Rob
>>
>> --
>> Robert Collins <rbtcollins@hp.com>
>> Distinguished Technologist
>> HP Converged Cloud
>>
>>
>