On 26.11.25 22:35, Eric Rescorla wrote:
On Wed, Nov 26, 2025 at 1:17 PM Muhammad Usama Sardar
<[email protected]> wrote:
I think the draft should have a statement somewhere stating that
it is no longer compliant with the base TLS specs, with pointer to
section 9.1 of RFC 8446bis.
I don't think that's correct.
Yeah, sorry, as mentioned in the thread, please take my comments with a large grain of salt, since I haven't yet worked with PQ. I am most likely missing something from implementation perspective, from PQ perspective, from terminology perspective or interpretation of terms. So please feel free to ignore.
My general feedback for this draft was that since it is the first draft on pure PQ that we have, I would have expected it to give a much better introduction and motivation than a couple of sentences that basically tell me nothing about why this draft even exists. For example, "users that want ..." is too generic of a motivation that would apply to almost any draft of the IETF. Specifically, I would like to know more about those users to be able to reach out to them to ask whether they also want attestation. If motivation comes from compliance, I would like to read those regulations to understand whether these regulations also require attestation. And if the answer to any of those is yes, then check out whether these users have any preference about intra-handshake attestation vs. post-handshake attestation, etc.
An implementation could choose to implement just the new algorithm andnot the MTI algorithm(s) in the same class, in which case the implementationwould be noncompliant, but it's possible to be noncompliant based purely on the algorithms registered in RFC 8446, for instance by implementing just P-384 and not P-256.
Sure, but I feel like there is a difference. In this case, the implementers /choose/ not to implement P-256 while still having the possibility, whereas in pure PQ, implementers have /no possibility/ to support P-256. Isn't it?
That is, I don't understand how pure PQ can support P-256. So my point was that implementations which have pure PQ cannot be "TLS-compliant applications", as per section 9.1 of 8446bis.
-Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
