On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an > attempt to make the story more explicit by adding a new post_handshake > extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable are > not needed. Some types of connections/implementations don't need to support > key updates (some unidirectional connections), session tickets (pure PSK > implementations) and post-handshake client auth (most browsers). These are > all currently SHOULDs in the spec and they don't need to be.
Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that additionally continues the handshake hash. KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth). Furthermore, the post-handshake authentication mechanism doesn't look to be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, And there are serious questions about how it should interact with applications. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
