On Wed, Nov 26, 2025 at 1:17 PM Muhammad Usama Sardar < [email protected]> wrote:
> On 26.11.25 21:44, Eric Rescorla wrote: > > Right, though it's important to be clear on what that means: > > - You have to support key_share, but you don't necessarily need to send it > (e.g., if you're doing pure PSK without any DH). > > cool, thanks very much. That resolves the apparent mismatch between > section 9.1 and Figure 1 in my head. > > - The requirement for key_share doesn't require you to do ECC, just to > support the extension generally. You'd be in compliance with this > particular MUST if you supported pure MLKEM, though of course not with the > MUST to support P-256. > > I think the draft should have a statement somewhere stating that it is no > longer compliant with the base TLS specs, with pointer to section 9.1 of > RFC 8446bis. > I don't think that's correct. In general any draft which defines a new algorithm just allows that algorithm to be used in TLS, but doesn't otherwise affect TLS. This is true for this draft but also for the MLKEM-ECC hybrids. An implementation could choose to implement just the new algorithm and not the MTI algorithm(s) in the same class, in which case the implementation would be noncompliant, but it's possible to be noncompliant based purely on the algorithms registered in RFC 8446, for instance by implementing just P-384 and not P-256. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
