On Mon, Oct 20, 2025 at 8:10 AM Simon Josefsson <[email protected]> wrote:
> Eric Rescorla <[email protected]> writes: > > >> *EKR wrote:*>It's purely about whether we think it's reasonable to > implement. > >> > >> This is the current meaning. RFC8447bis will change the meaning to: > >> > >> “This only means that the associated mechanism is fit for the > >> purpose for which it was defined.” > > > > Right. Is it not the opinion of the TLS WG that P256/P-384 + MLKEM are > fit > > for that purpose? > > RFC8447bis requires IETF-consensus. I don't think that question has > been asked IETF-wide at all so far, has it? Has there been any > consensus call in the TLS WG on that question even? So we don't really > know. > RFC 8447bis has already been IETF Last Called and approved by the IESG, and is in the RFC Editor Queue now. https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ > If not, on what basis, given that we require you to implement P-256 alone? > > I don't think this comparison with historic MTI of P-256 alone is > relevant for deciding about P256+MLDSA today. > It's not just historic. RFC 8446bis (also in the RFC Editor queue) continues require it. https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ It is reasonable that we required you to implement something a couple of > years ago that we wouldn't require you to implement today, but we > haven't gotten around to publishing an updated document. > As above, we are in fact publishing an updated document which requires it. Compare the migration away from MD4, MD5, DSA, DES, RC4. The tendency > to move beyond those algorithms happened long time before we got around > to drop them from recommended/MTI status Well, MD4, RC4, and DES were never MTI in TLS at least. the MTI in TLS 1.2 was: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ( https://www.rfc-editor.org/rfc/rfc2246#section-9). I tend to agree with you about DSA. Even at the time TLS 1.0 was published, RSA was far more common, but as you know, there were concerns about IPR. MD5 is a special case because it was baked into the core of SSLv3 and TLS 1.0, so you had to implement it as part of the transcript hash, but, as noted above, it was not MTI otherwise. The concept of "Recommended=Y/N" didn't apply at the time these algorithms were in wide use. By that line of reasoning, it would make sense to standardize and make > MTI the brainpoolP256 curve too. I don't think that is reasonable > today, so I think the analogy is invalid as an argument. > I don't understand this line of reasoning at all. The TLS WG made a specific decision about what curves to make MTI at the time TLS 1.3 was specified and decided not to include Brainpool. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
