On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar <sub...@fb.com> wrote: > > I brought up an alternate construction in BKK for > draft-wood-tls-external-psk-importer-00 which might have some potentially > better properties. I didn't get time to explain then, so here it is: > > One issue I think with the current construction in the draft with external > psk is that if the client uses the external psk with a different hash > function due to configuration error, then it turns into a fatal connection > error because TLS endpoints are required to tear down the connections on > binder mismatch. The client does not recover until it stops using the > external psk. > > An alternate approach to solve this could be to have a construction like: > > [hash of (psk identity + ImportedIdentity)] [psk identity] > > A server that uses the psk would perform the following steps during the > resumption > > Negotiate the cipher suite to use > If an external psk is used, strip off the first hash length of the psk > identity where the hash length depends on the cipher suite. > Compute the hash of pskidentity + imported identity and compare it against (2) > If it doesn't match, don't use the PSK and fallback to full handshake. > > > I think this a subtle change, because if you treat this case as if you were > not willing to use the PSK, then you can ignore the binder. This might be > operationally easier to deploy and reason about than a hard failure.
Thanks for writing this down! This is certainly an interesting proposal. That said, in cases where one might use external PSKs, failing hard seems like a fine (and probably preferred?) outcome. I'd be happy to hear of cases where one might want to fall back to a full handshake. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
