At the very least, I think that everyone on this list can agree that the process needs more transparency on the communication between WG and FATT.
That is a major concern for me. In addition, given the difficulty which has faced consensus-making on TLS with ML-KEM and ML-DSA, formal analysis in these areas can only be helpful in allowing us to reach a decision. On Tue, Apr 28, 2026, at 10:13 AM, Felix Linker wrote: > 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] > Nadim Kobeissi Symbolic Software • https://symbolic.software
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
