Hi S. Moonesamy,

Sorry for the length. TL;DR is cost of transparency is zero since the thing is already happening behind the scenes.


I am going to use two terms:

   /Initial/ FATT review: which is just after adoption [0]

   /Final/ FATT review: which is just before WGLC [1]


I would like to add one more (hopefully reasonable -- of course all my arguments are reasonable to me; the question is whether they are not reasonable to someone in the WG) argument that it's not just the WG asking questions. It's actually the other way around as well, for example:

1. At /initial/ FATT review, FATT may have questions from authors as
   well as Verifiers. For the former, to understand better the threat
   model and desired security goals, etc. to be able to suggest which
   approach is best-suited (see [*] below). For the latter, to better
   understand what formal analysis approach and tool is being
   planned/currently used (if any).
2. During /final/ FATT review, FATT may have questions on what the
   Verifier has done, especially in cases where a peer-reviewed
   publication is not yet available. We are not yet there for any of
   the drafts to be able to say much here (and hence I cannot present
   any evidence here) but I think many of you will agree that
   evaluating someone else's code is not easy, or at least if you have
   the opportunity to talk to that person, it will decrease the brain
   cycles that you will have to spend on it.

And it is worth repeating: both of the above still happen today but privately; the proposal is just to make it transparent. Hence, there is not much additional burden on any stakeholder in my proposal. The proposed mailing list provides a transparent way without creating noise on this mailing list.


On 25.04.26 07:54, S Moonesamy wrote:
At 04:20 PM 24-04-2026, Muhammad Usama Sardar wrote:
The other feedback I got for FATT contact in this thread is 'there are reasonable arguments to be made.' It's not fully clear to me whether the implication is to say that my arguments are not reasonable. Hence, my questions to you:    * mind sharing if you feel my arguments in [1] and here are reasonable?
   * and if possible, which argument is lacking?
   * It would be helpful if you could share: which potential risks and gaps do you view in my proposal other than FATT not responding?
I noticed that what I described looks like a catch-22 {1] after sending my previous reply.

I do not share that opinion. Luckily, we already have a way-out for this "catch-22" problem. If FATT members do not respond, they lose their opportunity for their opinions to be considered. We cannot wait forever for them. We discussed it a couple of years ago when formulating FATT process and my understanding is that the process we settled on [1] is very clear on that (/emphasis/ my own):

   The assessment (/if provided/)[...] If the FATT /fails to provide
   output within a reasonable time frame/ as determined by the working
   group chairs the processing of the document should /continue as normal/.

Hence, I can imagine the same thing to apply in my proposal. If FATT does not respond to our questions on the new proposed list, we just continue with the best judgement. What do you think?


I did not find anything in the arguments which you sent which were not reasonable.

Thank you. That's actually very helpful.


  I would factor in the human element as that's generally where a mechanism which looks good fails to deliver the desired results.

Could you please explain what 'human element' means in the context of my proposal?


The "no response" could turn into a problem.  It's not possible to do anything about that because of the catch-22.

I acknowledge this problem, which already exists today. I don't see any new catch-22 introduced by my proposal. I think we have a way-out as mentioned above.

If I have misunderstood something, please clarify more explicitly. Thank you.


Best,

-Usama

1. https://www.oed.com/dictionary/catch-22_n

[0] https://github.com/tlswg/tls-fatt#document-adoption

[1] https://github.com/tlswg/tls-fatt#working-group-last-call-wglc

[*] For example, there is evidence available on list and in meeting 125 that this happened for draft-ietf-tls-extended-key-update.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to