Subject: Re: New Version Notification for draft-ietf-httpbis-http2-encryption-05.txt

From: Erik Nygren <[email-masked]>
Date: Wed, 1 Jun 2016 11:34:19 -0400

On Tue, May 31, 2016 at 2:02 AM, Mark Nottingham <[email-masked]> wrote:

> FYI; this incorporates the discussing in WGLC.
>
> Please have a look at it; if any issues remain unresolved, please bring
> them to our attention ASAP.
>

As we've been doing some detailed design of a server-side implementation,
as well as had some internal security folks looking more closely, some
additional items/questions have arisen:

1) Prohibit mixing scheme (HTTP vs HTTPS) on a connection without
authenticated server-side opt-in:
https://github.com/httpwg/http-extensions/issues/188

2) Is there anything that can trigger fall-back to clear-text HTTP?  In
particular, what is client-side handling when a server returns a 421 (Not
Authoritative) over a strongly authenticated connection?  Should clients
error, fall back to clear-text just once, or remove their cached
commitment?

3) The text is still a little unclear on whether commit then requires
subsequent connections to use "strong authentication" or just
"authentication".  In particular, Section 3 seems to add some confusion
about whether "reasonable assurances" and "server authentication" are the
same thing or not but then 5.2 sometimes uses "authenticated without
"strongly authenticated".  For example, this paragraph is not particularly
crisp on what the requirements are (strong authentication or something
else):

   A commitment is not bound to a particular alternative service.
   Clients are able to use alternative services that they become aware
   of.  However, once a valid and authenticated commitment has been
   received, clients SHOULD NOT use an unauthenticated alternative
   service.  Where there is an active commitment, clients SHOULD ignore
   advertisements for unsecured alternative services.  A client MAY send
   requests to an unauthenticated origin in an attempt to discover
   potential alternative services, but these requests SHOULD be entirely
   generic and avoid including credentials.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Jun 2016 10:08:05 +1000

> On 2 Jun 2016, at 1:34 AM, Erik Nygren <[email-masked]> wrote:
> 
> Please have a look at it; if any issues remain unresolved, please bring them to our attention ASAP.
> 
> As we've been doing some detailed design of a server-side implementation, as well as had some internal security folks looking more closely, some additional items/questions have arisen:
>  
> 1) Prohibit mixing scheme (HTTP vs HTTPS) on a connection without authenticated server-side opt-in:  https://github.com/httpwg/http-extensions/issues/188 

See separate thread.

> 2) Is there anything that can trigger fall-back to clear-text HTTP?  In particular, what is client-side handling when a server returns a 421 (Not Authoritative) over a strongly authenticated connection?  Should clients error, fall back to clear-text just once, or remove their cached commitment?  

As I read it, if there's no tls-commit, the client can always fall back. If there is, it can't while that commitment is in effect.

> 3) The text is still a little unclear on whether commit then requires subsequent connections to use "strong authentication" or just "authentication".  In particular, Section 3 seems to add some confusion about whether "reasonable assurances" and "server authentication" are the same thing or not but then 5.2 sometimes uses "authenticated without "strongly authenticated".  For example, this paragraph is not particularly crisp on what the requirements are (strong authentication or something else):
> 

I had a similar reaction reading this earlier. Martin, do you want to do some tweaking, or should I have a go?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Erik Nygren <[email-masked]>
Date: Wed, 1 Jun 2016 21:34:40 -0400

Another issue that came up from one of our security researchers which
is not covered in the doc is client certs.  Do we need any guidance on them
in the doc?
Should we say that clients MUST NOT send them for connections being used
for HTTP-scheme
requests?  Or only send them after an origin has opted-in with a
.well-known/http-encryption response
over a strongly authenticated connection?

The risk comes from an unauthenticated active adversary Alt-Svc'ing a
client to a server
to which the client is sending client certs for HTTPS but where the server
is not
multi-scheme aware and hasn't opted in.  There is the potential for the
server to
have a perception of HTTPS client-cert authenticated requests when the
client may
be thinking it is making HTTP requests which may have had some cookies
or other elements injected by the active MitM under the cleartext HTTP side.

   Erik

On Wed, Jun 1, 2016 at 8:08 PM, Mark Nottingham <[email-masked]> wrote:

> > As we've been doing some detailed design of a server-side
> implementation, as well as had some internal security folks looking more
> closely, some additional items/questions have arisen:
> >
> error, fall back to clear-text just once, or remove their cached commitment?
>
> As I read it, if there's no tls-commit, the client can always fall back.
> If there is, it can't while that commitment is in effect.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Jun 2016 11:51:53 +1000

I would be happy saying that you can't use client certs.  That is,
unless you were using them for HTTPS requests and the connection
happened to be shared.

On 2 June 2016 at 11:34, Erik Nygren <[email-masked]> wrote:
> Should we say that clients MUST NOT send them for connections being used for
> HTTP-scheme
> The risk comes from an unauthenticated active adversary Alt-Svc'ing a client
> to a server

---

From: Erik Nygren <[email-masked]>
Date: Wed, 1 Jun 2016 21:52:51 -0400

That seems like a good way to address the concern/issue.

On Wed, Jun 1, 2016 at 9:51 PM, Martin Thomson <[email-masked]>
wrote:

> for
> client