Re: [TLS] post-handshake auth: multiple CertificateRequests, fewer replies?

[David Benjamin <[e-mail]>]

Our implementation considers all post-handshake CertificateRequests to be a
fatal error to avoid this. We would do the same even with this proposal;
it's an unnecessary complexity (which translates to security risk). If the
protocol is such that the client will always bulk-disavow a burst of
unexpected CertificateRequests, the server shouldn't have sent them.

This was the motivation for wanting it controlled by application profile (
https://github.com/tlswg/tls13-spec/pull/680) and also our general dislike
of this feature. It's the sort of thing where semantics are very
application-specific and thus belongs in the application protocol, not TLS.

Alas, since HTTP/1.1 lacks a nice place to inject this, post-handshake auth
is needed to match the legacy renegotiation hack. But, with an application
protocol, we can make nice protocol-specific simplifying assumptions and
cut out all the pointless cases full generality forces a receiver to
tolerate.

For instance, in (unpipelined) HTTP/1.1:

1. A client first writes its entire HTTP request, then it tries to read the
HTTP response.
2. The server reads the HTTP request. If it decides it needs client auth,
it buffers the entire request and sends CertificateRequest. It then tries
to read the client Certificate..Finished before sending any part of the
HTTP response.
3. The client reads a CertificateRequest and considers it in response to
this HTTP request.
4. The client picks a client certificate and sends Certificate..Finished.
It goes back to reading the HTTP response.
5. The server reads this, checks it, and, if satisfied, sends the HTTP
response.
6. Any deviation from this exact flow is an unexpected post-handshake
message thus a protocol error. This includes:
  * Server sending CertificateRequest mid-response body.
  * Server sending 1,000 CertificateRequests when there's no HTTP request
on the pipe. [Although this'll just read as being in response to the next
HTTP request.]
  * Client sending application data sent between the HTTP request and
Certificate..Finished.
  * Client sending application data between Certificate and
CertificateVerify.
  * Client sending Certificate..Finished mid POST body.

The key here is "unexpected" is an application-specific idea. For most
applications, everything is unexpected and thus should be the default. For
applications that use this, "unexpected" is more complex.

In other words, you should think of post-handshake auth not as a thing the
TLS stack processes, but as an extra dimension of complexity in the TLS <->
application substrate. Just as application data record HTTP/1.1 syntax
error is protocol error, so should a CertificateRequest with HTTP/1.1
post-handshake-auth "syntax error".

David

On Tue, Dec 13, 2016 at 4:37 PM Benjamin Kaduk <[e-mail]> wrote:

> 4.5.2 Post-Handshake Authentication notes that if a client receives
> multiple CertificateRequests, it can reply to them in a different order
> than they were received.  By my reading of the text, the client is still
> "obligated" to respond to all of them (but the server has to be able to
> receive an arbitrary number of messages before it gets back the response,
> so it's kind-of a weak obligation).  Would we want to weaken the
> restriction so that the client is only obligated to reply to at least one,
> similarly to how a peer can coalesce multiple KeyUpdate requests?  I
> understand that the setup is somewhat different, since the
> CertificateRequest comes with a context and could correspond to different
> application-level needs, but it seemed worth mentioning, since as we have
> discussed before generating the Finished message comes with some burden of
> handshake buffering/hash forking/etc.
>
> -Ben
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>