Ya I think failing hard depends on the use case for the external psk. For example if external psk is your own source of identity then ya you can't really fallback, however if you are using external psk as an optimization or something else, then falling back might be desirable.
Subodh ________________________________ From: Christopher Wood <christopherwoo...@gmail.com> Sent: Monday, November 5, 2018 6:56:57 PM To: Subodh Iyengar Cc: <tls@ietf.org> Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00 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
