Re: Report on preliminary decision on TLS 1.3 and client auth

[Ilari Liusvaara <[e-mail]>]

On Wed, Sep 23, 2015 at 10:16:42AM -0700, Martin Thomson wrote:
> 
> The security claims associated with client authentication require more
> analysis before we can be certain, but the basic idea is that
> authentication merely provides the proof that a server needs to regard the
> entire session to be authentic. In other words, client authentication will
> apply retroactively. This could allow a request sent prior to
> authentication to be considered authenticated. This is a property that is
> implicitly relied on for the existing renegotiation cases and one that we
> might want to exploit.
> 
> Each certificate request includes an identifier that allows it to be
> correlated with the certificate that is produced in response. This also
> allows for correlating with application context. This is what I think that
> we can use to fix HTTP/2.

How do you deal with server sending reauthentication request (even associated
with some stream) when client has unauthenticable streams (no credentials or
cross-origin coalescing)?

Reset the streams blocking authentication? Refuse identity change? Open
a new connection?

Also, what if after authentication no credentials request is made?
Refuse request with network error? Open a new connection?


With CANT+CARE, it was pretty obvious that client would just route requests
to connections (if needed, opening a new one) in order to deal with these
kind of issues.

> Clients cannot spontaneously authenticate, which invalidates the designs I
> have proposed, however, the basic structure is the basis for the first
> option that I will suggest.

>From some comments it seems "unsolicited client auth" isn't about CARE type
stuff but client just plain sending its CC/CCV mid-connection?


-Ilari