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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
