Report on preliminary decision on TLS 1.3 and client auth

[Martin Thomson <[e-mail]>]

The minutes of the TLS interim have been posted. Some decisions regard
client authentication were made.

https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3

Here is a summary of the applicable pieces, plus what I options it provides
HTTP/2...

(Caveat here: aspects of this could change if new information is presented,
but it seems unlikely that there will be changes that will affect the core
decisions.)
The big change is that a server can request client authentication at any
time. A server may also make multiple such requests. Those multiple
requests could even be concurrent.

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.

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.


Option 1 uses a new authentication scheme. A request that causes a server
to require a client certificate is responded to with a 4xx response
containing a ClientCertificate challenge. That challenge includes an
identifier.  The server also sends - at the TLS layer - a
CertificateRequest containing the same identifier, allowing the client to
correlate it's HTTP request with the server's CertificateRequest.

Client@HTTP/2:
HEADERS
  :method = GET ...

Server@HTTP/2:
HEADERS
  :status = 401
  authorization = ClientCertificate req="option 1"

Server@TLS:
CertificateRequest { id: "option 1" }

Client@TLS:
Certificate+CertificateVerify { id: "option 1", certificates... }

Client@HTTP/2:
HEADERS
  :method = GET ...

Server@HTTP/2:
HEADERS
  :status = 200


Option 2 aims to more closely replicate the experience we get from
renegotiation in HTTP/1.1 + TLS <= 1.2.  Rather than rejecting the request,
the server sends an HTTP/2 frame on the stream to indicate to the client to
expect a CertificateRequest. That frame includes the identifier.

Client@HTTP/2:
HEADERS
  :method = GET ...

Server@HTTP/2:
EXPECT_AUTH
  id = option 2

Server@TLS:
CertificateRequest { id: "option 2" }

Client@TLS:
Certificate+CertificateVerify { id: "option 2", certificates... }

Server@HTTP/2:
HEADERS
  :status = 200

In this case, the server probably wants to know that the client is willing
to respond to these requests, otherwise it will want to use
HTTP_1_1_REQUIRED or 421.  So a companion setting to enable this is a good
idea (the semantics of the setting that Microsoft use for renegotiation is
pretty much exactly what we'd need).

I think that the first option has some architectural advantages, but that
is all.  The latter more closely replicates what people do today and for
that reason, I think that it is the best option.


As for how to implement this same basic mechanism in TLS 1.2, I have an
idea that will work for either option, but it's a bit disgusting, so I'll
save that for a follow-up email.