> On 22 Feb 2025, at 5:06 am, Salz, Rich via dnsdir <dns...@ietf.org> wrote: > > Thank you for the careful reading! > >> NIT: Should the enumeration of the known deficiencies of TLS 1.2 be contained >> in the Introduction? The same considerations are described in Section 6, and >> their summation in the Introduction seems to be superfluous. > > I'm happy to move item #1 from the intro into section 6 and replace the > paragraphs with a pointer. See > https://github.com/richsalz/draft-use-tls13/pull/4
works for me! > >> NIT: the assertion in section 3 that "TLS applications will need to migrate >> to >> post-quantum cryptography" is ddependent on the expectation of the lifetime >> of >> the integrity of the encrypted object. The current advice on the immediate >> need >> to use PQC is based on an integrity lifetime of 20 years.I would feel better >> if >> the sentence read "many TLD applications..." > > I don't understand. TLS is generally more about privacy of communications > rather than the integrity of the content. Are you conflating this with object > signing and encryption (JOSE, CMS, PGP, etc)? So firstly let me quickly recap my understanding of the issues with the need for PQC. AS I noted to ekr a day ago I can't find the NIST document thought I has seen this. Encryption algorithms are intended to protect a payload from being "broken" by some adversary. This means that the encryption needs to be able to resist attacks using currently available computing resources. However, thats not the full story. The question is: "over what period of time tin the future do you want to maintain this protection? I recvall a US NIST stipulation that a secure encryption algorithm used for secret material needs to be resistant to such attack for a period of 20 years. The corollary is that IF you are looking for this level of security, then you need to use PQC right now. However the state of the art of quantum computation capability today is up to finding the prime factots of 21, so if your required lifetime of integrity of secrecy is, say one month, then its hard to support the case that you need tpo use PQC right now. Now the assertion in the draft that: "Cryptographically-relevant quantum computers, once available, will have a huge impact on TLS traffic." is true, for what its worth, but its reasonable to predict that this will not be the case for the coming couple of years, or even the coming five years. see https://www.potaroo.net/ispcol/2024-11/pqc-fig1.png taken from a NANOG 92 presentation from October 2024. If we are looking at drivers for the immediate deployment of post-quantum cryptography, the Digital Signature application space is generally not a compelling motivation. The most practical current response to the quantum threat is to use public key certificates with reasonably short lifetimes so that the window of vulnerability to future attack is limited. For session Key Establishment the problem is somewhat different. If the entirety of a session can be captured by a third party, then the initial setup that establishes the session key is also captured. This initial setup is protected by a crypto exchange, so that the generation of the session key is a private act between the two parties. The session capture can be replayed to a capable quantum computer, this would allow the session key generation to be exposed, and the entire session contents can be decoded at that time. The only defence against this attack from the future is to shift to use the quantum-resistant algorithm now, and perform key exchange using this algorithm. So if the sense of the advice in section 3 refers to the use of a crypto exchange to protect the privacy of the subsequent session then the key consideration is: "What is the period over which you think that such privacy protection ios necessary? If your answer is "20 years" or even 15 years, then you really need to use PQC right now! Not "migrate" but "right now". On the other hand if you don't have such a requirement then the advice about the shirt fo PQC algorithms need not be so strident. So the two sentences in section 3 of this draft gloss over a larger set of considerations. The first sentence is true, but without some associated estimate of WHEN such cryopto-relevant quantum computers will tools will be available its a very anodyne observation. Your own need to use PQC is based on a) your estimate as to when such tools wil be available and b) how long you want to maintain the integrity of privacy. > >> NIT: Section 4: "As a counter example, the Usage Profile for DNS over TLS >> [DNSTLS] specifies TLS 1.2 as the default, while also allowing TLS 1.3." I >> fail >> to appreciate the rationale for including this - the text is careful to note >> that this applies to new protocols and DNS over TLS is not a new protocol at >> this state. > > We thought it worthwhile to point to a counter-example from previous specs, > but if it is confusing, I can remove it. I would like to ask the WG to weigh > in before doing so. As a reviewer I found it confusing enough to note as a NIT. But there is just one of me and its just a NIT! Others may have different views of course. cheers, Geoff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
