Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message and we see that client certificate verification is allowed for some PSK exchanges and not others, and that the PSK exchanges used in resumption are ones where it is allowed. (Maybe I am reading that wrong) Right now this feels footgunny to me: you have to track where the PSK came from to decide if client auth is allowed.
I'd like to see an explicit separation by indicating where the PSK came from in the ciphersuite, and then implementations reject authentication with one of them. This way someone who wants to do the wrong thing is at least forced through enough contortions they will notice, rather than seeing two features that seem to work together but don't. TRON is in 2 days, and I'm concerned that the degree of analysis of TLS 1.3 is far below where I would like to see with the timelines some people are pushing for. I think it's clear that TLS 1.3 implementations will never be as secure and as simple as QUIC or CurveCP. At the same time we've diverged from TLS 1.2 enough that implementations will be significantly complicated when supporting both, the reason given for not massively simplifying the protocol in the first place. Sincerely, Watson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
