Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Russ Housley <> Tue, 21 May 2019 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0087F120043 for <>; Tue, 21 May 2019 06:54:18 -0700 (PDT)
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 SIq5tJSPyxqD for <>; Tue, 21 May 2019 06:54:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AFF2120041 for <>; Tue, 21 May 2019 06:54:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AFA5300ABC for <>; Tue, 21 May 2019 09:34:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 2w6AsffgMDeF for <>; Tue, 21 May 2019 09:34:56 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown []) by (Postfix) with ESMTPSA id 6E88F3005AB; Tue, 21 May 2019 09:34:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <>
In-Reply-To: <m28sv03b6y.fsf@localhost.localdomain>
Date: Tue, 21 May 2019 09:54:13 -0400
Cc: Joe Salowey <>, IETF TLS <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <m28sv03b6y.fsf@localhost.localdomain>
To: Geoffrey Keating <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk
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: Tue, 21 May 2019 13:54:18 -0000

> The last call has come and gone without any comment.  Please indicate if
>> you have reviewed the draft even if you do not have issues to raise so the
>> chairs can see who has reviewed it.  Also indicate if you have any plans to
>> implement the draft.
> I looked at the draft.
> My understanding of the draft (and I think it would have helped if it
> contained a diagram showing the resulting TLS handshake) is that it's
> specifying the existing psk_dhe_ke flow, to which it adds a
> certificate-based signature over the handshake, which it doesn't
> specify but works the same way as in RFC 8446 when there is no PSK.

I am pleased to add text that will make it more clear, but you are the first one to ask.

Please see slides 5 and 6 of the presentation at IETF 104:

> This is somewhat confusing because the draft is written as if it
> starts with a certificate-based TLS flow and somehow adds a PSK; it
> repeats all the RFC 8446 PSK machinery, but doesn't explain how the
> certificate interacts with it, and raises questions like "are there
> two DH operations or just one?".  I think the draft could have been a
> lot shorter.

One (EC)DH exchange.

I agree that there is a fair amount of context in the draft.  That was an attempt to avoid the confusion that you claim in the previous paragraph.

> Conversely, one area where the draft could have been longer would be to
> explain how exactly this produces quantum-resistance in the presence
> of a secret shared key.  It appears that it relies on the HKDF-Expand
> function being quantum-resistant.  That seems like an important thing
> to document, given that we don't have fully functional quantum
> cryptanalysis yet and so don't know exactly what might be
> quantum-resistant or not.

Hash functions are quantum-resistant.  Shor's algorithm means that you might want to use one that 2x longer than previously chosen.  The same is true for symmetric encryption algorithm keys.

I can add a paragraph to the security considerations that HKDF and the underlying hash function are assumed to be quantum-resistant.

> However, once you're past that, the resulting protocol seems quite
> simple (as an addition to psk_dhe_ke) and I have no objections to it.