Subject: [TLS] PSK and client verify

From: Watson Ladd <[email-masked]>
Date: Fri, 19 Feb 2016 10:25:29 -0800

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 11:59:31 -0700

> 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

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>