Hi Nick and Kris,
On 7/12/26 14:44, Nick Sullivan wrote:
Hi Kris,
I think we agree, but I want to be clear on one point: we should
restrain ourselves from creating a hard dependency on the CFRG
publishing a draft for this document. The security considerations
document for ML-KEM has been discussed in the CFRG but is has not
yet been adopted (discussion is ongoing). Given the targeted nature
of this suggestion and the attention it has from experts
participating in this WG, having to block on a CFRG publication for
one recommendation would be overkill. Working groups are free to
make their own cryptographic decisions.
I agree with not creating a hard dependency. I also hope that the CFRG
makes the decision to restore Kyber's hash even though there are no
protocol police.
I agree that entropy and RNG compromise should be taken into
consideration in a CFRG draft on this topic if adopted so that other
working groups can benefit from this type of advice, but not as a
blocker for this document.
This is a very short draft worth writing if it is simply restoring
Kyber's hash. Is that the scope you're thinking for a CFRG draft?
If so, I agree that such a draft should not block this document but I
think the issue of restoring Kyber's hash is a blocker on the draft
under discussion on the tls list. That and a lack of consensus, of course.
The TLS WG chairs always have the option
to solicit an expert review from the Crypto Review Panel on any
sensitive cryptographic elements of a protocol if they deem it
necessary.
Part of the issue here is the threat model considerations. For some
people this is an absurd attack. For others it is outside their
mathematical concept of the hardness assumptions. For large-scale
adversaries, they don't care about such distinctions, they just want to
win. Lets not make it blindly obvious and easy for them.
Kind regards,
Jacob Appelbaum
Best, Nick
On Sun, Jul 12, 2026 at 12:07 PM Kris Kwiatkowski
<[email protected]> wrote:
On 12/07/2026 09:06, John Mattsson wrote:
Regarding Jakob Appelbaum's suggested text, I agree that wording
along the lines of "the m value is recoverable by the
decapsulating peer" should be added to draft-ietf-tls-ecdhe-mlkem,
draft-ietf-tls-mlkem, and likely to future IETF KEM specifications
as well.
I agree with the points below, including that the broader CSPRNG
guidance discussion belongs in a wider IETF context such as an
RFC4086bis effort.
On where the suggested text about 'm' being recoverable by the
decapsulating peer should go: I think draft-sfluhrer-cfrg-ml-kem-
security-considerations is the proper home for it, rather than the
documents that merely define code points for TLS. The TLS drafts
could then simply reference it. Duplicating ML-KEM security
considerations across draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-
mlkem, and every future KEM code point document seems fragile, and
a single CFRG document keeps the guidance consistent. This follows
the same logic as your RFC4086bis suggestion: put the guidance
where it can be referenced, not in each protocol-specific draft.
For the same reason, the discussion itself belongs in CFRG, where
it would get review from the crowd focused on cryptographic
mechanisms.
Cheers, Kris _______________________________________________ TLS
mailing list -- [email protected] To unsubscribe send an email to tls-
[email protected]
_______________________________________________ TLS mailing list --
[email protected] To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
