Hi list, I think there is at least another issue that still needs to be discussed: how to properly handle post-handshake handshake messages.
The subject has also been raised several times on GitHub (https://github.com/tlswg/tls13-spec/pull/680, https://github.com/tlswg/tls13-spec/pull/676, https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html). Bottom line is: - handling client late authentication requires a lot of state in the client stack - currently, handling client late authentication is mandatory For a longer version, post-handshake records of type Handshake can be of three kinds: - NewSessionTicket (sent by the server, and that can safely be ignored entirely by clients) - KeyUpdate (sent by either party, requiring only a bit of state) - CertificateRequest (sent by the server, an arbirary number of times, and requring the client to keep some state *for each request*) Of course, this last item makes the post-handshake client state machine explode, whereas the first two items can ben implemented in a trivial way. The client can not indeed ignore all this state to answer, since it is supposed to answer at least with a Finished message, which will cover the CertificateRequest message. Moreover, since each of these Finished messages must cover the initial handshake and the current CertificateRequest message, it requires a forkable hash implementation, which requires more memory. A client _could_ ignore CertificateRequest and never answer them, but this would not really be conformant, and it would be problematic as soon as the parties need to send Handshake messages. Thus, I believe the current text is inadequate. Different solutions are possible : - remove client late authentication entirely (this would have my preference, since it introduces other issues*) - make client late authentication optional (compatible clients would signal it as an extension) - rethink the client late authentication, as was done with KeyUpdate, to limit the state required on the client side. Best regards, Olivier Levillain * One of these issues is that requiring Client Authentication upon an applicative request may lead a client to have to write records on a SSL_read call : 1) client and server complete the handshake 2) client sends a request (SSL_write) 3) server reads the request, decides an authentication is required, and sends a CR 4) client reads the response (SSL_read), but has first to comply with the CR (that is write packets) to get the response This violation of the network layers can be dealt with (and has been, since Apache allows eactly this kind of flow) but it introduces complexity in the code, which I belive we should remove altogether : an application request should not trigger an SSL authentication request. What was done with KeyUpdate sanitized a similar situation. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
