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

On Tue, May 31, 2016 at 2:02 AM, Mark Nottingham <mnot@mnot.net> 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.