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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 17:50:57 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/

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

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

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

* 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/

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Dec 2019 09:34:25 -0500

Roman:

Thanks for the careful read and the resulting comments.

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.

> generate, distribute, manage the external PSKs is out of scope for this

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.

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

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