I'm also opposed. If this document were *only* about the FATT process, that may something the WG might consider, incorporating the preferences of the FATT, which seems not to have been done here.
However, this does not seem to actually be what this document is. This document is extremely focused on the WG's draft-ietf-tls-mlkem work, mixing individual views on subjective tradeoffs with much more limited formal method results. It then embeds a request to send it to the FATT as part of the process proposal. Due to this extra rider in the proposal, I am opposed. Formal methods are very useful, but the questions surrounding draft-ietf-tls-mlkem are not ones that formal methods would help with. On Mon, Apr 27, 2026 at 2:52 PM Filippo Valsorda <[email protected]> wrote: > I’m opposed: it doesn’t sound like we heard from any FATT members about > this? The scarce resource here is their time, we should do whatever works > best for them (and secondarily try not to block things unnecessarily on > them, which means I am especially opposed to anything in > https://muhammad-usama-sardar.github.io/tls-fatt-extension/draft-usama-tls-fatt-extension.html > that > would have made a trivial addition of a key exchange algorithm like ML-KEM > block on FATT). > > 2026-04-27 20:26 GMT+02:00 Salz, Rich <[email protected]>: > > > - I think we have converged on the hybrid proposal. Anyone else got > any opinions? In particular, anyone opposing the proposal? > > I’m opposed; I think it is too early to change the way the FATT works. > _______________________________________________ > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
