On Fri, Feb 21, 2025 at 11:07 PM Geoff Huston <g...@apnic.net> wrote:
> 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. > I'm not sure this is quite the right way to think about it, for several reasons. First, there is a fair amount of uncertainty about the actual timeline of CRQCs. The link you provide provides group estimates of the probabilities of development of a CRQC over time, so it's not like if my data is only good for 5 years then I am definitely safe. Rather, there is some probability that I'm safe and some that I'm not. So, I think you have to think of this as more of a cost/benefit calculation. Suppose I have two secrets, one of which will cost me $5 if compromised any time over the next 50 years, and one of which will cost me $5 billion if compromised but only needs to be kept secret for the next 5 years, I think it's clear which one more needs to be protected with PQC. Second, it's very difficult to determine the necessary lifetime for specific pieces of information, especially from the perspective of a low layer protocol like TLS, which rarely has much of an idea of what's going across it. Even at the level of application protocols such as e-mail or Web, there is a huge variety of secret lifetimes in play. This isn't to argue for any particular piece of guidance, but just to say that I think it's hard to bound one's level of risk just by looking at the time period over which information needs to remain secret. -Ekr 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 > > > > _______________________________________________ > Uta mailing list -- uta@ietf.org > To unsubscribe send an email to uta-le...@ietf.org >
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
