On 8 October 2016 at 11:54, Eric Rescorla <e...@rtfm.com> wrote: > I could go either way on this. It seems like this pushes complexity from the > client to the server. > > Consider the case of NST. Presently, a client which doesn't want resumption > can just ignore NST, > but in your proposed change, the server needs to read this extension and > then conditionally send > NST, and the client still needs the logic to detect unexpected handshake > messages and abort > on them. > > As I said, I could go either way, and I do think it's potentially useful to > be able to say "I won't do > post-handshake client auth" and even more useful to be able to say "I would > do post handshake > message X which will be invented in 2018" (but of course we can register an > extension for > that then), but less useful to say "I don't like NST or KU"
I'm concerned about the information this exposes on the wire. We've added Record Content Type protection, so things like post-handshake client auth can't be detected on the wire (modulo behavior/length attacks, for which we can attempt protection with padding.) But now we're going to say in the client's plaintext "Yea, I might want post-handsake client auth". And it seems like the percentage of clients who will say that will be few and far between... leading to more fingerprinting and a step back from where we were. -tom _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
