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.
...
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."
...
The degree of vulnerability varies in significance depending on the application
and underlying systems.
...
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?
2. Conventions and Definitions
...
* Traditional Algorithms
...
The iETF is moving away from that word. Perhaps "non-quantum algorithm"
instead.
...
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.
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.
...
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.
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 ..."
...
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?
...
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?
...
• 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.
...
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 ?
...
Use Server Key Share Preferences Communicated via DNS
...
What about protocols that cannot use DNS, such as EAP?
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.
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?
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?
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".
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?
8.2. Hybrid public-key encryption (HPKE) and Encrypted Client Hello
...
To safeguard against "Harvest Now, Decrypt Later" attacks, ECH deployments must
...
MUST ?
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
