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

From: Erik Nygren <[email-masked]>
Date: Thu, 30 Oct 2014 18:36:32 -0400

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?

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.  In these
cases we may want to require key exchange via DHE/ECDHE but also pass along
an indicator so that clients requiring authentication can ignore that
Alt-Svc response.  For example,
returning this in a cleartext HTTP/1.1 response over port 80:

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

Would have the "noauth" token make it clear to clients not to expect
authentication.
I worry that without this we'll have similar interop issues where
some clients will follow the Alt-Svc expecting/requiring strong
authentication and will fail to connect when it is not present,
making it hard to use draft-ietf-httpbis-http2-encryption in any
practical manner, i.e.  for using http scheme HTTP/2 over unauthenticated
TLS for the purposes of getting past middleboxes (and for "opportunistic
security").

    Erik

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Oct 2014 16:40:03 -0700

> the same problems with 9.2.2?

We can tighten up the requirements, certainly.

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

---

From: Robert Collins <[email-masked]>
Date: Fri, 31 Oct 2014 15:35:19 +1300

> provide authentication.  I'd rather not have two mechanisms for the

Also wouldn't it deliver a trivial downgrade attack to folk who can
intercept and alter traffic?

-Rob

-- 
Robert Collins <[email-masked]>
Distinguished Technologist
HP Converged Cloud

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Oct 2014 10:24:48 -0700

> intercept and alter traffic?

This is already the case.  Hence this being opportunistic.

---

From: Michaela LaVan <[email-masked]>
Date: Fri, 31 Oct 2014 13:26:42 -0400

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.

---

From: Nicholas Hurley <[email-masked]>
Date: Fri, 31 Oct 2014 10:37:31 -0700

> This is already the case.  Hence this being opportunistic.

Actually, it is not necessarily already the case. It is true that, if
you get an Alt-Svc header over an http-schemed connection, yes, this is
already opportunistic. It also doesn't (in that case) deliver a
downgrade attack, since you can't really downgrade from anything non-TLS
:) In this case, having a noauth token is a no-op, and thus just a waste
of bytes.

If, however, you get an Alt-Svc header over an https-schemed http/1.1
connection (or an ALTSVC frame on an h2 connection), those will not
enable opportunistic encryption, as that *would* present a downgrade
attack for a MITM. In this case, having a noauth token to explicitly
enable a downgrade attack sounds like a bad idea.

Thus, I'm -1 on a noauth token.
-- 
Peace,
  -Nick

---

From: Erik Nygren <[email-masked]>
Date: Fri, 31 Oct 2014 14:56:55 -0400

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 <[email-masked]> 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 <
> [email-masked]> wrote:
>