Subject: [TLS] External PSK importers

From: Christopher Wood <[email-masked]>
Date: Mon, 29 Oct 2018 21:40:25 -0700

To resurrect the discussion around external PSKs and TLS 1.3, I wrote down the importer-based design Ekr and I discussed [1].

   https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/ <https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/>

Time permitting, I’d like to present this in BKK. It would be useful to compare and contrast this against David’s Universal PSK draft [2].

Thanks,
Chris (chair hat off)

[1] https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epHk6Q1Uw <https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epHk6Q1Uw>
[2] https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/ <https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 15:56:01 +1100

Happy to talk about this.

Based on a quick reading, a few notes:

You should do something more concrete with the label parameter.  Keep
in mind that both client and server need to agree on a use for this,
so my initial intuition to put the server identity might not work, but
it could be a start.  The problem being that how the client identifies
the server might not be something it shares with the server.

You equivocate regarding the hash to use.  If we're going to make this
solid, then we need to follow good hygiene and say that each imported
PSK needs to be used with just one hash function.

You equivocate again more than I like about TLS 1.2.  How about you
reserve a label specifically for TLS 1.2 and feed the PSK through the
expand function using that label?
On Tue, Oct 30, 2018 at 3:41 PM Christopher Wood <[email-masked]> wrote:
>    https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epHk6Q1Uw
> [2] https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 23:26:08 -0700

> the server might not be something it shares with the server.

There is also a privacy issue with the external identifiers. For session
tickets, this is solved by only using a given resume ticket once, but
that's harder with external PSK.

-- Christian Huitema

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Oct 2018 07:07:46 -0400

> On Oct 30, 2018, at 2:26 AM, Christian Huitema <[email-masked]> wrote:
> 

Christian:

Proclaiming that you have access to a particular external PSK may reveal that you as part of a group.  I do not see a way to completely avoid this because the PSK is input to the key schedule at the very top.  Thus, there is no key that could be used to encrypt it.

The importer described by Chris does provide some obfuscation of the base key identity, but an observer will be able to see each of the key identifiers that are derived, even if they cannot tell which one goes with a particular external PSK.  Padding with bogus key identifiers does not help either as the group membership may be revealed by watching which imported key identifier get selected by the server.

Russ

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Oct 2018 12:02:19 -0700

> Proclaiming that you have access to a particular external PSK may reveal that you as part of a group.  I do not see a way to completely avoid this because the PSK is input to the key schedule at th…

You do have a shared secret, the PSK itself. In the DNS SD privacy
proposal, we construct an obfuscated key identifier as
base64(nonce|truncated(hash(nonce|PSK))). In the simplest form, the
nonce is chosen randomly by the client, and the server has to try all
available keys until it finds one that matches.

We were worried about the compute cost of many trials, so we specified a
"predictable nonce" set to a "rounded time" -- in our case, the most
significant 24 bits of the 32 bit Unix time. The server would only have
to compute the set of hashes and potential identifiers once per time
interval. But that's of course a trade-off between obfuscation and
compute costs.

We were somewhat concerned about replay attacks, but that's a general
problem with PSK. An attacker could repeat the client hello, and see
whether the server's response provides information about the server
identity. Hopefully, TLS 1.3 takes care of that.

My point however is not to propose specific solutions, but rather to
ensure that the documents that we produce acknowledges the privacy
concerns with key identifiers. Once we agree that this is indeed an
issue, we can debate the appropriate solution.

-- Christian Huitema