On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > > that's not workable. > > > It's not great, however > > > > the reason why implementations chose to use old API to provision TLS > > 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling TLS > > 1.3 is quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most uses, > and seems the only way forward. > Do you have an alternative solution?
I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after the release TLS 1.3, even if you consider it small fragmentation. Correct solution was to include it in the TLS 1.3 proper. Now we have a TLS 1.3 draft which says: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. and a proposed change to it that doesn't say anything about differentiating between universal binders and regular binders. And forces those new binders to SHA-256 where previously it was selectable. So, either it is a severe issue and we should rework TLS 1.3 draft, or this draft needs to be significantly reworked before it will not cause huge interoperability headaches – signalling extension is the bare minimum, most likely a new PSK extension is necessary. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
