"The goal of the FATT process is to maintain the high degree of cryptographic assurance in TLS 1.3 ..."
Just for saving a few bytes or a performance boost? Can someone prove that pure ML-KEM is more secure than hybrids? If not, then why degrade the security?
I request the WG to converge towards /parking/ this draft and revisiting it at some point in the future when the FATT report is available and substantial amount of changes have been made to this draft.
If I am misunderstanding something in the following, please feel free to correct me.
On 21.02.26 23:51, Eric Rescorla wrote:
I am mostly indifferent to whether this document is eventually published, though sad that we're spending so much time debating it in the WG, given the relatively minimal practical effect of publication.
I'm sad, too, for different reasons:
1. It breaks all our existing formal analysis (e.g.,
draft-fossati-tls-attestation [0,1] and in general [2,3]) and our
ongoing efforts for formal analysis of:
* draft-ietf-tls-extended-key-update
* draft-ietf-tls-pake
* draft-fossati-seat-expat
2. I personally view this WGLC as a potentially unnecessary debate
since the prerequisites for FATT process seem to have clearly not
been fulfilled, in particular [4]:
> When a document is adopted by the working group the chairs will
make a determination whether the change proposed by the document
requires review by the FATT to determine if formal protocol analysis
is necessary for the change. For example a proposal that modifies
the TLS key schedule or the authentication process or any other part
of the cryptographic protocol that has been formally modeled and
analyzed in the past would likely result in asking the FATT, whereas
a change such as modifying the SSLKEYLOG format would not. The
working group chairs will inform the working group of this decision.
As I mentioned in [5], I did search on the list but could not find any
evidence of any such email "informing the working group of this
decision." I haven't seen anyone pointing me to such an email of chairs
close to adoption time either. Did I miss something? If not, this
appears to be a process violation, i.e., the WG has neither been
informed nor given an opportunity to discuss/rebut the decision.
With due respect to Peter, from a formal analysis perspective, I view his comparison [6] of draft-ietf-tls-hybrid-design with this draft largely as a comparison of "apples concatenated with oranges" vs. "oranges-only". I believe the former with "apples" part will still preserve our existing proofs but the latter clearly does not. IMHO, from formal analysis perspective, a closer (but still not ideal) reference data point is RFC8773bis, and not draft-ietf-tls-hybrid-design, since the former has gone through FATT review. Even if someone wants to compare with draft-ietf-tls-hybrid-design, I believe this mlkem-07 draft is a security degradation compared to that one.
While I have no reason to doubt the analysis of Thom and Huguenin-Dumittan pointed on the list and very much respect both works, my understanding from a very quick skim is that neither Thom nor Huguenin-Dumittan has modeled key reuse case. Thom, is this correct? In general, it seems to me that both Thom (Sec. 2.5.1) and Huguenin-Dumittan (Sec. 5) acknowledge that with reusing keys, forward secrecy property will be lost. Independently, I also believe such analyses cannot substitute FATT review in the process.
Since this draft clearly seems to be controversial, I am still failing to see why chairs are not asking for expert review of FATT to resolve the matter. So, I once again request the chairs to initiate FATT process. Maybe chairs can collect all related analysis and send these pointers along with the request.
While I agree with you about duplication and that text in this section (if written precisely) may be sufficient without this diagram, IMHO it is better to have a pictorial illustration. If you do not have a strong opinion, I will suggest to keep it as is.S 4.3. Here too, the diagram seems duplicative, so I would remove it.
I agree. If I assume there is no attacker in between two honest peers, proofs hold trivially. If I assume I share secrets with honest peers /only/, proofs hold trivially. In both cases, proofs are pretty much useless.The shared secret output from the ML-KEM Encaps and Decaps algorithms over the appropriate keypair and ciphertext results in the same shared secret shared_secret as its honest peer, which is inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, as shown in Figure 1. I don't know what "honest" is doing here. If you connect to a malicious peer, you might still get a shared secret.
I believe an informative draft should not use normative language /anywhere/ in the draft. Please correct me if I am wrong.S 5.2. While it is recommended that implementations avoid reuse of ML-KEM keypairs to ensure forward secrecy, implementations that do reuse MUST ensure that the number of reuses abides by bounds in [FIPS203] or subsequent security analyses of ML-KEM. Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts. This kind of normative language doesn't belong in Security Considerations. If it's important it should go elsewhere.
[0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.png
I couldn't follow what that was related to. I see that you cite [0] once but that is to CNSA profile and that has a separate reference [0] above. In any case, TLS 1.2 and below don't have PQ support, so why is it mentioning TLS 1.0 and TLS 1.2? Do you think there is something we should fix in TLS specs or is it just implementation-related issue?
Thanks. -Usama [0] https://github.com/CCC-Attestation/formal-spec-id-crisis[1] https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
[2] https://www.researchgate.net/publication/396245726_Perspicuity_of_Attestation_Mechanisms_in_Confidential_Computing_Validation_of_TLS_13_Key_Schedule
[3] https://mailarchive.ietf.org/arch/msg/seat/x3eQxFjQFJLceae6l4_NgXnmsDY/ [4] https://github.com/tlswg/tls-fatt?tab=readme-ov-file#document-adoption [5] https://mailarchive.ietf.org/arch/msg/tls/M-dTIUXdG_x7OtweBcOCp0bFcZQ/ [6] https://mailarchive.ietf.org/arch/msg/tls/Ge7x7wsumhwDaMXnhYFk5BaCbUs/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
