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

[Benjamin Kaduk <[e-mail]>]

On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker wrote:
> 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.

I'll leave this one for the authors.

> - 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.

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