[TLS] Re: [New-wg-docs] I-D Action: draft-ietf-tls-ecdhe-mlkem-00.txt

2025-03-27 Thread Sun Shuzhou
Hi Viktor,

Thanks for the detail explanation.


> Noting the sizes in an order that is different from the wire order is not 
> IMHO a significant issue, given explicit language defining the wire order 
> elsewhere, ... though of course switching the order of exposition, just in 
> case someone might somehow miss the definitive text, would be fine.

This caused some unnecessary confusion in understanding. Otherwise I won't ask 
it.

Cheers,
Shuzhou
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org


[TLS] Re: [New-wg-docs] I-D Action: draft-ietf-tls-ecdhe-mlkem-00.txt

2025-03-27 Thread Sun Shuzhou
Hi,

I have read this draft and have two questions.

1. X25519MLKEM768 is the concatenation of ML-KEM and X25519.  Why 
SecP256r1MLKEM768/SecP384r1MLKEM1024 use a different order? ML-KEM part comes 
after the EC share.

2. In Section 3.1.3. Server share:

When the SecP256r1MLKEM768 group is negotiated, ... The size of the server 
share is 1153 bytes (1088 bytes for the ML-KEM part and 65 bytes for secp256r1).

When the SecP384r1MLKEM1024 group is negotiated, ... The size of the server 
share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1)

   If the intended order is (EC part || ML-KEM part), it is more appropriate to 
write:

When the SecP256r1MLKEM768 group is negotiated, ... The size of the server 
share is 1153 bytes (65 bytes for secp256r1 and 1088 bytes for the ML-KEM part).

When the SecP384r1MLKEM1024 group is negotiated, ... The size of the server 
share is 1665 bytes (97 bytes for secp384r1 and 1568 bytes for the ML-KEM part).


Cheers,
Shuzhou

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org


[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

2025-04-01 Thread Sun Shuzhou
Hi,

I'm opposed to adoption.

I share the same concern with Stephen.

The conservative hybrid key exchange way should be preferred.

Cheers,
Shuzhou
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org