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

Geoffrey Keating <> Tue, 21 May 2019 00:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D791F1200EA for <>; Mon, 20 May 2019 17:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m2tUyRz1TaGO for <>; Mon, 20 May 2019 17:25:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 971D0120090 for <>; Mon, 20 May 2019 17:25:58 -0700 (PDT)
Received: by (Postfix, from userid 501) id DEA6333D2B3; Tue, 21 May 2019 00:25:57 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Joseph Salowey <>
Cc: "<>" <>
References: <> <>
From: Geoffrey Keating <>
Date: 20 May 2019 17:25:57 -0700
In-Reply-To: <>
Message-ID: <m28sv03b6y.fsf@localhost.localdomain>
Lines: 32
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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 00:26:01 -0000

Joseph Salowey <> writes:

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

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.

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.

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.