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

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

On Wed, Jun 1, 2016 at 9:51 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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 <erik@nygren.org> wrote:
> > 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/
> >>
> >
>