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

Benjamin Kaduk <> Fri, 08 January 2021 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB34C3A0F2F; Thu, 7 Jan 2021 16:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zctmc1oej580; Thu, 7 Jan 2021 16:39:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECF393A0F22; Thu, 7 Jan 2021 16:39:36 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 1080dT0L022815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 19:39:33 -0500
Date: Thu, 7 Jan 2021 16:39:28 -0800
From: Benjamin Kaduk <>
To: Martin Duke <>
Cc: The IESG <>,,,,
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-external-psk-importer-06: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jan 2021 00:39:40 -0000

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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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).