Is it not possible to construct a channel binding for whatever underlying protocol was used to agree the PSK and use that as the PSK identity. If the PSK was created in TLS 1.2 then that would be something derived from `tls-unique`.
The security of a channel binding is not dependent on it being secret, and thus using it as the PSK identity is safe. Doing this would prove agreement on the KDF used, and would be bound to the handshake by the PSK binders. Assuming that the KDF was something acceptably secure, this would mitigate the risk of collisions between hash outputs, because which hash function was used to produce the PSK would be an agreed value. That would also require no changes to the key schedule, which is perhaps lower risk. This of course assumes that both parties agree that this is how the PSK identity was constructed, so it would probably need an extension. Regards, Jonathan On Fri, 15 Jun 2018 at 15:25 Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> 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? > > _______________________________________________ > 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
