Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

Russ Housley <> Thu, 01 March 2018 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E32EA12FAD0 for <>; Thu, 1 Mar 2018 14:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qyda9iN_uMhD for <>; Thu, 1 Mar 2018 14:14:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C0F312FACF for <>; Thu, 1 Mar 2018 14:14:47 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79E57300687 for <>; Thu, 1 Mar 2018 17:14:45 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id Gw5ITwGSAP2j for <>; Thu, 1 Mar 2018 17:14:44 -0500 (EST)
Received: from new-host-5.home ( []) by (Postfix) with ESMTPSA id 41E55300435; Thu, 1 Mar 2018 17:14:44 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <>
In-Reply-To: <>
Date: Thu, 01 Mar 2018 17:14:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00
X-Mailman-Version: 2.1.22
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: Thu, 01 Mar 2018 22:14:49 -0000

> This seems like a welcome addition.  I'm not sure why you think that
> PQ needs are a good motivation for this work though.  Managing
> external PSKs is so unwieldy that it almost seems like this would do
> more harm than good in that regard.  I find this more interesting from
> the perspective of providing continuing proof of possession for keys
> while also permitting the use of 0-RTT (and session continuation more
> generally).

The key management would be pretty onerous if a different external PSK is distributed to each client-server pair.  I was pretty careful to make sure that the key schedule would work out even if the external PSK is know to a group of clients and a group of servers because the (EC)DHE key will be pairwise.

If the external PSK is not pairwise, I do not think it can be used for 0-RTT traffic, which is why the I-D does not allow early data.

> FWIW, I don't see any reason that this approach would be a problem
> given that it is additive, the problem that Sam Scott et. al. from
> before was a result of important contextual information being omitted
> from the transcript.

I did not see a problem, but we should make sure that there is not something subtle.

> Why didn't you consider a new codepoint on psk_key_exchange_modes that
> permits/requires use of the certificate?  The purpose of that
> extension is to signal that a) you want PSK, and b) what additional
> things are permitted alongside that PSK.

Because of this text in the TLS 1.3 base specification:

   ... Implementations MUST NOT
   combine external PSKs with certificate-based authentication of either
   the client or the server unless negotiated by some extension.

That steered me toward an additional extension.

> It's not clear from your text on client certificate authentication
> whether your mode permits the server to omit its Certificate, but then
> send CertificateRequest.  You should clarify that one way or other.

That was intended by:

   When the "tls_cert_with_extern_psk" extension is successfully
   negotiated, authentication of the server depends upon the ability to
   generate a signature that can be validated with the public key in the
   server's certificate.  This is accomplished by the server sending the
   Certificate and CertificateVerify messages as described in Sections
   4.4.2 and 4.4.3 of [I-D.ietf-tls-tls13].

But I see that it should be reworded to include a MUST statement.