Subject: [TLS] Martin Duke's Discuss on draft-ietf-tls-external-psk-importer-06: (with DISCUSS)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 04 Jan 2021 15:40:34 -0800

Martin Duke has entered the following ballot position for
draft-ietf-tls-external-psk-importer-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is probably just my own ignorance, but I see two potential problems in Sec
4.1.

- 'The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the
serialized content of ImportedIdentity is used as the  content of
PskIdentity.identity in the PSK extension.' IIUC ImportedIdentity has a maximum
length of 2^17 + 2. But the Identity field in the PSK option has a maximum
length of 2^16-1. I presume this never actually happens, but the spec should
handle the boundary condition, perhaps by limiting the first two fields of
Imported Identity to sum to 2^16-5 bytes or something.

- It says 'Endpoints SHOULD generate a compatible "ipskx" for each target
ciphersuite they offer.' but then the example shows two ciphers that equire
only one derived key. Do you mean "hash algorithm" instead of "ciphersuite"?
TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are different
ciphersuites according to RFC 8446.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Jan 2021 16:39:28 -0800

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

I'll leave this one for the authors.

> ciphersuites according to RFC 8446.

TLS 1.3 ciphersuites are associated with a Hash, and 8446 assumes that HKDF
with that Hash is the KDF for use of that ciphersuite.  This document
somewhat extends that to allow a more generic KDF, rather than just HKDF,
but "compatible with a ciphersuite" means "compatible with the KDF
associated with the ciphersuite", and since the Hash and HKDF are the same
for the two ciphers, the same ipskx works for both (and an efficient
implementation would be expected to only compute it once).

Thanks,

Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Jan 2021 16:57:23 -0800

On Thu, Jan 7, 2021 at 4:39 PM Benjamin Kaduk <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

I can see how someone would want this, but in practice that's not how it's
generally done in TLS. Trying to compute the precise upper bounds gets
complicated very fast when there are multiple fields. We do generally
try to get the lower bound right, though even then there have been
mistakes:

https://github.com/ekr/tls13-spec/pull/56/files

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Tue, 19 Jan 2021 10:33:50 -0800

Hi Ben,

IIUC this means that while one must generate the ipskx for each
ciphersuite, but these might turn out to be the same. I found the language
to be somewhat unclear here, but I will remove the DISCUSS on this subject
and leave it to the authors if they want to make it a bit clearer.

---

From: Martin Duke <[email-masked]>
Date: Tue, 19 Jan 2021 10:40:12 -0800

Ekr,

I appreciate that this is hard to represent in 8446 notation. Would it be
possible to add some text in 4.1 that says "Due to the maximum size of the
PSK extension, the external_identity and context fields MUST sum to a
length of 2^16-5", or something to that effect?

IMO, it would be unfortunate if the PSK Importer interface allowed
parameters that result in undefined behavior on the wire.

If this is unworkable or very very dumb for some other reason, I am willing
to accept that feedback.

Martin