[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informat ional RFC

Hi Dan, dear Joe, dear Chair, and all auditorium,

since Dan mentioned my name in this message:

Am Dienstag, dem 11.08.2026 um 10:50 +0000 schrieb D. J. Bernstein:
> 
> As yet another example, some statements beyond the 82 mentioned above
> sound to me like opposition (e.g., Erwin Hoffman's statement) but
> don't
> phrase this in an unambiguous way. 

I like to put a personal comment here, though knowing it might not be
in consensus with the lists code-of-conduct:

1. Unlike Dan, I don't consider automatically former state employees or
contractors as unwelcome proponents of that draft. 
Why? I need to disclose:
- In 1990+ I was working for an US company 'Spartacus' providing DARPA
TCP/IP services for IBM mainframes ('KNET') based on 'MIL-STDS'. My
first 'customer' was indead 'Fort Meade' (maybe some veterans on this
list will remember).
- Later, I was contractor of the BSI in Germany to setup the
'Bundesbehördennetz' implementing X.400 services.
- I also worked for the German 'Bundeswehr' as contractor.

Thus, according to that history, I probably will fail.
Later, (1998+) I used DJB's software for my customers and given that
experience, I feel comfortable with it and the general scope of Dan's 
approaches, which I try to extend (see my web page) and keep alive.

2. As 'fresh' member of this mailing list, I simply feel not to be
entitled to give a definitive go/nogo here. Rather, I tried to focus on
some important issues not discussed [1]. 

3. However, I feel very uncomfortable about the way the discussion of
that draft is going on. Given my understanding (and supporting TLS 1.3
since its first beginning), the main purpose of a communication and
security-aware protocol is risk-minimization or at least risk-
migitation for the user. That is the baseline and should be obeyed at
each and every step (enforced by the Chair).

4. The way the random number is used in ML-KEM, does IMHO not conform
to this basic assumption: It is fed directly (not taking the
transcript-hashes into account) to generate the Master Secret [2].
Correct me, if I'm wrong.

5. Thus, at the bottom-line, the Master Secret depends solely of the
quality of the PRNG. As explained in [1], its Algorithmic Information
Content (AIC) is preserved given the ML-KEM handshake.
This is a clear violation of risk-minimization because of disclosing
its origin. Additional hashing would involve some additional
computational cycles, of course. 
However, the draft's final recommendation - in result - can be compared
with RSA (public) keys allowing to identify the underpinning generating
mechanism [3]. (German: Nicht alles was hinkt, ist ein Vergleich; for
the 'young ladies' here).

Only if those explainations are given as SECURITY advices in the draft,
I would support it. Otherwise, it leaves risks unmentioned which are
simply avoided in a hybrid case - or - in a extended version involving
hashing (HKDF would do). Joe did not take that chance - or at least,
did not mentioned the risks explicitely. 

Thus, I don't favor publishing this as RFC in the current version. 
Apart from this: I consider this as a poor RFC. Technical details
should be placed in tables (to be subject of references) and not in
bullitems with lots of redundancy; information flow between peers need
to be shown explicitely. The interconnection with the TLS RFC 9846 is
practically absent. 

Sorry for the long mail. This is just my humble oppinion.

--eh.

[1]
https://mailarchive.ietf.org/arch/msg/tls/Q-ZAH0cyd6vM1iG0QreHDtan0dg/
[2] https://www.fehcom.de/qmail/smtptls.html##keyMgmt
[3]https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/svenda

-- 
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 36553F7F9C58D1CC
PGP key-fingerprint:  950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC

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

-----BEGIN PGP SIGNATURE-----

iKAEABYKAEgWIQSVC1VVCwhaKhwAlZQ2VT9/nFjRzAUCanuUJRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDMOHGZlaEBmZWhjb20uZGUACgkQNlU/f5xY0cw1HgD/
YGr1fHHCvJVnaS/GD3iMD6BZ1Kdy+Obe8JRi71fU6LAA/Ri/FVUWcrU2l+1Rchkf
TC8UIdyYPb0uM+20sTOKjWYH
=iO0W
-----END PGP SIGNATURE-----