W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Thu, 24 Sep 2015 22:21:58 +0300
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20150924192158.GA13323@LK-Perkele-VII>
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?

Received on Thursday, 24 September 2015 19:22:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC