The major thing that this proposal achieves is that it makes post-handshake auth an optional part of the implementation. Instead of this, I would also be in favor of a simpler change that modifies the text to say that post-handshake CertificateRequest messages are fatal by default and only permitted if the application permits their use in a given context (say if the application is HTTP 1.1, only directly after requests).
Embedded implementations may choose to simply fail on unexpected CertificateRequests, and that way not have to implement any code around post-handshake finished messages or updating the transcript when one arrives. This default wording should also apply to other types of post-handshake messages, though NST and KU could be exceptions that should always be supported and non-fatal. On Tue, Oct 11, 2016 at 9:37 AM Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > Hi Nick, > > given my discussion with Martin in this thread > https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like > your idea of making the post-handshake messages optional since it allows > me to develop a TLS 1.3 client that is smaller in code size. > > Ciao > Hannes > > > On 10/08/2016 03:03 AM, 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. > > > > In order to simplify the logic around dealing with post-handshake > > messages, this proposal makes support for each of these modes explicit > > via a new handshake extension. This change also makes the path to > > introducing other types of post-handshake messages in future drafts more > > explicit. > > > > PR: > > https://github.com/tlswg/tls13-spec/pull/676 > > > > Nick > > > > > > _______________________________________________ > > 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
