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

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 <mnot@mnot.net> wrote:

>
> > On 2 Jun 2016, at 1:34 AM, Erik Nygren <erik@nygren.org> wrote:
> >
> > 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
>
> 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):
> >
> >    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.
>
> 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/
>
>