Hi Alan, Thanks for the review. Please see inline
On Thu, 28 Aug 2025 at 18:52, Alan DeKok <aland= 40deployingradius....@dmarc.ietf.org> wrote: > This is a preliminary review of draft-reddy-uta-pqc-app. It focusses > mostly on nits, as I don't claim to be a crypto / quantum expert, despite > having a graduate degree in in nuclear physics. :) > > 1. Introduction > > Item (2). Is it would be useful to list some sample / average sizes > inline here, as I-Ds are not stable references. > It seems you are referring to ietf-pquip-pqc-engineers, it will become an RFC soon. > > ... > Any application transmitting messages over untrusted networks is > potentially vulnerable to active or passive attacks by adversaries equipped > with CRQCs. > ... > > I don't see how CRQCs are special here. Perhaps instead "by many > adversaries, including those equipped with CRQCs." > Fixed as follows: Any application transmitting messages over untrusted networks is potentially vulnerable to active or passive attacks by adversaries, including those equipped with CRQCs. > > ... > The degree of vulnerability varies in significance depending on the > application and underlying systems. > Good point, updated text. > ... > > And perhaps on the value of the data being transmitted, or the value of > attacking a particular individual / device / flow. > > ... > It also discusses how TLS client and server implementations, along with > essential supporting applications > ... > > What's an "essential" supporting application? Is Signal essential? Or > Netflix? > We meant essential supporting protocols like DNS; fixed text. > > 2. Conventions and Definitions > > ... > * Traditional Algorithms > ... > > The iETF is moving away from that word. Perhaps "non-quantum algorithm" > instead. > No, IETF WG documents and RFCs are using "traditional algorithms" (for instance, see https://datatracker.ietf.org/doc/rfc9794/). > > ... > Post-Quantum Algorithm: An asymmetric cryptographic algorithm designed to > be secure against attacks from both quantum and classical computers. > ... > > There are examples of algorithms given in the previous paragraph. Is it > possible to give a short description how an algorithm is post-quantum > algorithm? Or what makes it post-quantum? This might be a bit much to > ask, tho. The field is complex. > I added a line: Such algorithms rely on mathematical problems (e.g., lattices) that are believed to be hard for both classical and CRQCs to solve efficiently. > > 3. Timeline for Transition > > ... > The risk of "Harvest Now, Decrypt Later" (HNDL) attacks demands immediate > action to protect data confidentiality, > ... > > Perhaps give a reference here to convince the reader that this attack is > real. > Added reference to https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-14.html#section-7 > > ... > For data authentication, the concern shifts to potential on-path attackers > equipped with CRQCs capable of breaking traditional authentication > mechanisms. > ... > > Perhaps "existing / non-quamtum / historic" instead of "traditional". > There are multiple other uses, so I won't point the rest out. > Fixed text as follows: For data authentication, the concern shifts to potential on-path attackers equipped with CRQCs capable of breaking certificate-based authentication mechanisms that rely on traditional algorithms. > > 4. Data Confidentiality > > ... > Data in transit may require protection for years, > ... > > This is an odd phrasing. "in transmit" is usually interpreted as > "temporary", so may not be clear why it needs long protection. The > previous section explains this, so perhaps instead > > "The previous section explains why data that is only temporarily in > transit may still need protection for years ..." > Thanks, fixed. > > ... > Applications utilizing (D)TLS that are vulnerable to "Harvest Now, Decrypt > Later" attacks MUST transition to (D)TLS 1.3 > ... > > How is this transition done? Do they change the defaults? What impact > could that have on the application? > > > Many applications simply rely on the underlying TLS library to do all > TLS related work. Can the application simply upgrade the TLS library, and > be safe, or are there other steps that it needs to take? > Good point, updated draft. > ... > The client initiates the TLS handshake by sending a list of supported key > agreement methods in the key_share extension. One of the key challenges > ... > > The second use of "key" has a very different meaning from the first > use. Perhaps the second "key" could instead be changed to "important" or > "critical". > > ... > The size of the hybrid key exchange algorithm key share may exceed the > Maximum Transmission Unit (MTU), potentially causing the ClientHello > message to be fragmented across multiple packets > ... > > Does only applied to DTLS, and not TLS? > It applies to both DTLS and TLS. > > ... > • Middleboxes that do not handle fragmented ClientHello messages > properly may drop them, as this behavior is uncommon. > ... > > Middleboxs are also known to not handle fragmented UDP packets. That > should be mentioned too, as the problem is larger than just ClientHello. > Good point, fixed. > > ... > If the server supports hybrid key exchange, it will use the > HelloRetryRequest to request a hybrid key exchange algorithm key share from > the client. The client can then send the hybrid key exchange algorithm key > share in the second ClientHello message. > ... > > Do fragmentation issues affect the HelloRetryRequest ? > Fragmentation is not a concern for the HelloRetryRequest itself, as it is small. > > ... > Use Server Key Share Preferences Communicated via DNS > ... > > What about protocols that cannot use DNS, such as EAP? > For EAP-TLS where out-of-band configuration is not feasible, what do you see as the most appropriate way to convey these preferences ? > > > 5. Use of External PSK with Traditional Key Exchange for Data > Confidentiality > > Another issue with PSKs is impersonation. Anyone who has the PSK can > pretend to be either client or server. This should be mentioned, but it is > independent of any quantum issues. > Good point, updated text. > > 6. Authentication > > ... > For example, telecom networks—characterized by centralized infrastructure, > ... > > The dash makes for an odd sentence. Perhaps replace it with "..., which > are ..." > > If telecom networks are well-positioned, what effect does this have on > others / end users? And what happens with networks which are not > well-positioned? > It would delay the availability of PQ authentication in such deployments; added text for clarity. > > 6.1. Optimizing PQC Certificate Exchange in TLS > > ... > TLS Cached Information Extension > ... > While this mechanism reduces bandwidth usage, it introduces potential > privacy concerns > ... > > Does TLS 1.3 not encrypt these exchanges? i.e. is this only an issue > for TLS 1.2 and earlier? > In TLS 1.3, the certificate is encrypted but not the ClientHello (In this case, the client includes fingerprints of cached objects in the ClientHello). > > 7. Informing Users of PQC Security Compatibility Issues > > ... > The client, in turn, can notify end-users > ... > > What if this is not possible? Historically EAP supplicants are terrible > about producing any messages other than "failed". > In such cases, implementers would have to ensure sufficient diagnostic logging or telemetry is available for administrators to diagnose PQC-related interoperability problems. Updated text accordingly. > > 8.1. Encrypted DNS > > ... > However, encrypted DNS messages transmitted using TLS may be vulnerable to > decryption if an attacker gains access to the public keys used in the TLS > key exchange. > ... > > This is the same attach as mentioned earlier? > Yes, updated text. > > 8.2. Hybrid public-key encryption (HPKE) and Encrypted Client Hello > > ... > To safeguard against "Harvest Now, Decrypt Later" attacks, ECH deployments > must > ... > > MUST ? > The section is updated to align with the work happening in the HPKE WG. I raised a PR https://github.com/tireddy2/pqc_uta/pull/25 to address your comments. Cheers, -Tiru > > _______________________________________________ > 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
