Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Ilari Liusvaara <[e-mail]>]

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