Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)

Russ Housley <housley@vigilsec.com> Mon, 23 December 2019 14:39 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622F6120026 for <tls@ietfa.amsl.com>; Mon, 23 Dec 2019 06:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In-0Vku49VWX for <tls@ietfa.amsl.com>; Mon, 23 Dec 2019 06:39:43 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32671200B7 for <tls@ietf.org>; Mon, 23 Dec 2019 06:39:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B2F89300B34 for <tls@ietf.org>; Mon, 23 Dec 2019 09:34:27 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eNsyzHjb073x for <tls@ietf.org>; Mon, 23 Dec 2019 09:34:24 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id A8F2A3005DB; Mon, 23 Dec 2019 09:34:24 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <157654745794.24469.3021505269125375774.idtracker@ietfa.amsl.com>
Date: Mon, 23 Dec 2019 09:34:25 -0500
Cc: IESG <iesg@ietf.org>, TLS Chairs <tls-chairs@ietf.org>, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <92554FDB-2404-4D3F-B7D1-4146E01EEBC0@vigilsec.com>
References: <157654745794.24469.3021505269125375774.idtracker@ietfa.amsl.com>
To: "Roman D. Danyliw" <rdd@cert.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XInqkFJT9ogw9U59Msw_X-gRbAc>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2019 14:39:44 -0000

Roman:

Thanks for the careful read and the resulting comments.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 7. The paragraphs that start with “In this extension, the external
> PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if
> the (EC)DH key agreement ..” seem to be saying the same thing differently.

Not really.  The first one is talking about the PSK preserving secrecy (probably should say confidentiality).  The second one is talking about forward secrecy.  I will merge the two paragraphs:

   In this extension, the external PSK preserves confidentiality 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.  Should the attacker be
   able compute the (EC)DH shared secret, the forward secrecy advantages
   traditionally associated with ephemeral (EC)DH keys will no longer be
   relevant.  Although the ephemeral private keys used during a given
   TLS session are destroyed at the end of a session, preventing the
   attacker from later accessing them, these private keys would
   nevertheless be recoverable due to the break in the algorithm.
   However, a more general notion of "secrecy after key material is
   destroyed" would still be achievable using external PSKs, if they are
   managed in a way that ensures their destruction when they are no
   longer needed, and with the assumption that the algorithms that use
   the external PSKs remain quantum-safe.

> * Section 7. It’s worth mentioning somewhere the obvious thing – how to
> generate, distribute, manage the external PSKs is out of scope for this
> specification.

Gladly.  I put it at the bottom of the third paragraph in Section 7, which now reads:

   Implementations must protect the external pre-shared key (PSK).
   Compromise of the external PSK will make the encrypted session
   content vulnerable to the future development of a large-scale quantum
   computer.  However, the generation, distribution, and management of
   the external PSKs is out of scope for this specification.

> * Section 7.  Per “TLS 1.3 [RFC8446] has received careful security analysis,
> and some informal reasoning shows that the addition of this extension does not
> introduce any security defects”, is there a citation for this “informal
> reasoning”?  Otherwise, it’s a soft statement.

The informal reasoning follows the paragraph, and I think the only reference would be my slides from IETF 104.

To make this clear, I will change "some informal reasoning" to "the following informal reasoning".

> * Editorial Nits:
> - Section 3.  Typo.  s/inclue/include/
> 
> - Section 5.1. Typo. s/extension are/extensions are/
> 
> - Section 5.1. /Most of those extension are not impacted in any way.  This
> section discusses the impacts on the other extensions./Most of those extension
> are not impacted in any way by this specification.  However, this section
> discusses the extensions that require additional consideration./
> 
> - Section 5.1.  Typo. s/may be know to other partiers/may be known to other
> parties/
> 
> - Section 5.1. Typo. s/know to other parties/known to other parties/
> 
> - Section 7.  Typo.  s/that external PSK/that the external PSK/

Two of these must have been fixed based on comments from others.  Anyway, they are all fixed now.

Russ