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 <bka...@akamai.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
