On Fri, Feb 19, 2016 at 11:25 AM, Watson Ladd <watsonbl...@gmail.com> wrote:
> 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 suspect we actually can relax this constraint and instead have a clear warning about the impact of sharing PSKs. -Ekr 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
