*
I haven't seen any objections to publishing with caveats, only
  *
lack of clarity as to whether that'd be sufficient to lay this
  *
to rest.

Here is the intended security considerations planned for the next version of 
the draft.  It can be found at 
https://github.com/tlswg/draft-ietf-tls-mlkem/pull/14. There have been somewhat 
lengthy discussions (well, not compared to the threads here:).  Depending on 
the timing of things, “working on” might get changed to “just published” and 
include an RFC number. :)

# Security Considerations {#security-considerations}

{{NIST-SP-800-227}} includes guidelines and requirements for implementations
on using KEMs securely. Implementers are encouraged to use implementations
resistant to side-channel attacks, especially those that can be applied by
remote attackers.

TLS 1.3's key schedule commits to the ML-KEM encapsulation key and the
ciphertext as the `key_exchange` field of the `key_share` extension is
populated with those values, which are included as part of the handshake
messages. This provides resilience against re-encapsulation attacks against
KEMs used for key establishment {{CDM23}}.

This document defines standalone ML-KEM key establishment for TLS 1.3.
A PQ/T hybrid combines
a post-quantum algorithm such as ML-KEM.
with a traditional algorithm such as
Elliptic Curve Diffie-Hellman (ECDH)
The IETF is working on an RFC that defines several such key
establishment mechanisms, ML-KEM with a combining ECDH in {{ECDHE-MLKEM}}.

Both documents have IANA registry entries with an `N` in the recommended
column. Quoting from the registry {{TLSREG}}, "\[this] does not necessarily 
mean that
it is flawed; rather, it indicates that the item ... has limited
applicability, or is intended only for specific use cases."
Those developing or deploying TLS 1.3 with either encapsulation method
will have to determine the security and operational considerations
when choosing which mechanism to support.

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to