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

Russ Housley <> Tue, 21 May 2019 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A28312009E for <>; Tue, 21 May 2019 12:46:12 -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 vcyDPItqo-P4 for <>; Tue, 21 May 2019 12:46:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FA2D120096 for <>; Tue, 21 May 2019 12:46:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3FCD300AE4 for <>; Tue, 21 May 2019 15:26:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id YnYaWZEl5idz for <>; Tue, 21 May 2019 15:26:50 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown []) by (Postfix) with ESMTPSA id 1475C300471; Tue, 21 May 2019 15:26:50 -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 15:46:07 -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 19:46:12 -0000

> On May 20, 2019, at 8:25 PM, Geoffrey Keating <> wrote:
> 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.

I think that the necessary property is that HKDF reman a PRF.

I suggest the following additions to the Security Considerations:

  If the external PSK is known to any party other than the client and
  the server, then the external PSK MUST NOT be the sole basis for
  authentication.  The reasoning is explained in [K2016] (see
  Section 4.2).  When this extension is used, authentication is based
  on certificates, not the external PSK.

  In this extension, the external PSK regains the forward secrecy if the
  (EC)DH key agreement is ever broken by cryptanalysis or the future
  invention of a large-scale quantum computer.  As long as the attacker
  does not know the PSK and the key derivation algorithm remains
  unbroken, the attacker cannot derive the session secrets even if they
  are able to compute the (EC)DH shared secret.

  TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
  upon the HMAC construction and a hash function.  This extension
  provides the desired protection for the session secrets as long as
  HMAC with the selected hash function is a pseudorandom function (PRF)

  [GGM1986]  Goldreich, O., Goldwasser, S., and S. Micali, "How to
             construct random functions", J. ACM 1986 (33), pp.
             792-807, 1986.

  [K2016]    Krawczyk, H., "A Unilateral-to-Mutual Authentication
             Compiler for Key Exchange (with Applications to Client
             Authentication in TLS 1.3)", IACR ePrint 2016/711, August