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

From: Subodh Iyengar <[email-masked]>
Date: Mon, 5 Nov 2018 17:55:54 +0000

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

  1.  Negotiate the cipher suite to use
  2.  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.
  3.  Compute the hash of pskidentity + imported identity and compare it against (2)
  4.  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.

Subodh

---

From: Christopher Wood <[email-masked]>
Date: Tue, 6 Nov 2018 09:56:57 +0700

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar <[email-masked]> wrote:
> 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.
>
>

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

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 6 Nov 2018 03:59:14 +0000

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 <[email-masked]>
Sent: Monday, November 5, 2018 6:56:57 PM
To: Subodh Iyengar
Cc: <[email-masked]>
Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00

Best,
Chris