Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Olivier Levillain <[e-mail]>]

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.