Re: [TLS] draft-wood-tls-external-psk-importer-00

[Christopher Wood <[e-mail]>]

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar <[e-mail]> 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