Hi everyone, I am opposed as well. Ekr, David and Filippo already make good points, which I agree with.
I view the FATT as a group of experts, who have a certain, rare skill set, and the FATT can provide helpful input to the TLS WG. I don't see it as a process that can be "bypassed." We're not in court here. I do not see how making the process of asking the FATT for help more expensive/rigid/formalized/... will help the WG. At most, it will reduce the input that the WG can receive from FATT. Best, Felix Am Di., 28. Apr. 2026 um 09:42 Uhr schrieb Nadim Kobeissi <[email protected]>: > I’m happy to volunteer as a FATT member. I’ve done prior work on the > formal analysis of TLS 1.3, am confident in my ability to produce further > work as required, and am willing to allocate the time. > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > > On 28 Apr 2026, at 2:03 AM, Muhammad Usama Sardar < > [email protected]> wrote: > > It will probably not change anything but just to share my last 2 cents on > this without going into a debate: > On 27.04.26 20:49, Filippo Valsorda 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 > > That's a very fair point and I see this as a perfectly valid reason for > opposition by *FATT*, but perhaps not by *WG members*. In my > understanding, it would likely save FATT time, as I mention in the draft > [0]. But if they oppose it, I'll just drop it, just like I dropped the > openness point a couple of years ago. > > I believe chairs will seek their input directly, as they might not be fine > with sharing their individual opinions. > > (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). > > FWIW, this appears to be largely orthogonal to the mechanism for > *contacting* FATT, which was the topic of this sub-thread. > > FWIW, this "trivial" addition has an opposition of several WG members in > my understanding. It is essentially blocked. It is not obvious to me how we > are going to unblock that without formal analysis. I don't think calling it > "trivial" will lead us anywhere. > > I am very surprised that a sincere effort to resolve the dispute and to > offer a statement for security considerations is labelled as 'block'-ing > draft by the WG members, especially given that the draft is already blocked > by the opposition of several WG members. > > Instead of spending more time and energies on resolving issues of ML-KEM, > I would rather let it remain blocked and do some useful work for other WGs. > > Thank you all for your time and energies on considering my proposals. I am > grateful to all for the discussion. > > Sincerely, > > -Usama > > [0] > https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-06.html#section-4.1.3-2.2.1 > _______________________________________________ > 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]
