Hi Usama, For those who haven't been following this effort, I'd like to provide a level set on status. At present, SEAL is being considered by the IESG for chartering [0]. The way this works is that IESG will ballot on a draft charter and then send it out for IETF LC, and then ballot on WG formation.
That means that at present there is no WG -- and it's possible one will not be chartered, though I think fairly unlikely -- and so nothing that happens has any formal status. Unless it's explicitly encoded in the charter is just background input to the WG. Specifcally that means that: - You can't really have consensus calls because there's nobody to officially call consensus. - You can of course have some people get together, but that's not a Design Team in the sense of RFC 2418 because there's no WG to charter the design team. I think it would be most helpful if people didn't try to do things that mimicked IETF WG processes until the WG actually existed. > # Quick background about security goals: > > At IETF 123, we presented our list of informal security goals for > attested TLS in the TLS WG [0], UFMRG [1] and RATS WG [2]. No new > security goals were brought to our attention in those meetings. Ekr > had some concerns in the TLS meeting and provided useful starting > point for discussion [3] and I am assuming that Ionut satisfactorily > clarified the concerns in the thread. I'm not sure if that's true or not. I'd have to see some actual substantive text in a draft, not a mailing list thread. What I've seen so far in drafts seems insufficient. > We would like to have SEAL FATT similar to TLS FATT. Since it is only > one draft and it is clear that it needs formal analysis, the task > would be to ensure that the formal analysis is on the right track. To > begin with, I am proposing a simple process where one month before > every IETF meeting, we would submit a one-pager progress report to the > FATT liaison. FATT reviews the progress in three weeks and sends its > recommendations. The recommendations will be discussed at the > meeting. This is just an initial proposal and I am open to other > ideas. I don't think this is a good idea. The reason for a TLS FATT is that TLS is regularly producing new drafts and needs some streamlined way to ask for input without bogging analysis experts down in the more mundane work of TLS WG. That's not the situation here, and a much better model is what we had in TLS 1.3 where analysis experts worked hand-in-hand with less academically inclined members of the WG to develop the protocol. Here too, you're of course welcome to set up a little group of your own, but it can't have any formal status until the WG is formed and the existence or nonexistence of said group doesn't constrain the WG in any way. -Ekr [0] https://datatracker.ietf.org/doc/charter-ietf-seal/ On Fri, Sep 12, 2025 at 7:29 PM Muhammad Usama Sardar < [email protected]> wrote: > Hi all, > > [ This email is being sent to all lists mostly for informational purposes > and to gather any further security goals and interested Design Team/SEAL > FATT members. Unless your response really relates to all the lists, please > consider responding only to SEAL (and any WG/RG you think is relevant to > your response). ] > > # *Quick background about security goals*: > > At IETF 123, we presented our list of informal security goals for attested > TLS in the TLS WG [0], UFMRG [1] and RATS WG [2]. No new security goals > were brought to our attention in those meetings. Ekr had some concerns in > the TLS meeting and provided useful starting point for discussion [3] and I > am assuming that Ionut satisfactorily clarified the concerns in the thread. > After switch over, the thread continued at SEAL [4]. At the conclusion of > the thread, there seems to be a full agreement that the goals presented in > [0,1,2] are sufficient to cover the large classes of attacks (under certain > assumptions) for systems that such protocols can be used for. > > I have revisited the expat chat [5] and I didn't find any new security > goal which is not covered in [0,1,2]. > > This is a quick check to see if there are any other security goals that > might be relevant, else we are assuming this (informal) milestone to have > been achieved. Of course, new goals may be required as we proceed further, > but this is kind of a consensus call based on the current knowledge. The > rationale for having it now is to have sufficient time before the meeting > to update the formal analysis, if required. > > # *Formal Analysis* *Design Team:* > > In expat chat [5], Mike proposed to have Design Team. I am welcoming folks > to join our Design Team for formal analysis. I have been using ProVerif but > having it analyzed in other tools would also be good. The Design Team has > already made some discoveries, including: > > - Classical Lowe's hierarchy is not suitable for one-way > authentication. For example, weak agreement doesn't make much sense to me > when the client is not authenticated, i.e., server cannot be sure of the > identity of the client. Client never sends the certificate in this case. > How can the server agree on client's identity? > - No Cloud Service Provider (CSP) -- including Microsoft and Google -- > (as of today) is out of Trusted Computing Base (TCB) [9]. > - High-severity attacks on pre-handshake attestation (RA-TLS) and > intra-handshake attestation (TLS-attest) (informal description at [7]). > > Please join us for further discoveries :) > > # *SEAL FATT Design Team*: > > We would like to have SEAL FATT similar to TLS FATT. Since it is only one > draft and it is clear that it needs formal analysis, the task would be to > ensure that the formal analysis is on the right track. To begin with, I am > proposing a simple process where one month before every IETF meeting, we > would submit a one-pager progress report to the FATT liaison. FATT reviews > the progress in three weeks and sends its recommendations. The > recommendations will be discussed at the meeting. This is just an initial > proposal and I am open to other ideas. > > Ideally, I would like to have the SEAL FATT = TLS FATT + UFMRG chairs + > some senior contributors of TLS, dependent on their availability and > willingness. Please let us know if you are interested. > > As I understand, we cannot approach TLS FATT directly. So could TLS chairs > please check with FATT if they would like to be on SEAL FATT? We are open > to the option of their collective feedback being brought to the WG, and any > procedural changes they would like. > > # *Plan*: > > To facilitate consensus and adoption of our draft [6] in the first SEAL > meeting, unless some new security goal pops up in this thread, I am hoping > to share a couple of preprints by the end of this month, which should give > a month for interested folks to read through it for more insightful > discussions in the meeting. One of them is introductory about remote > attestation, TLS and design space of attested TLS to bring everyone on the > same page, and second one is comprehensively covering the details of formal > analysis of RA-TLS and TLS-attest, and our proposed solutions. > > In expat chat [5], Benjamin shared a helpful resource about Whatsapp using > RA-TLS [8]. We will have some interesting stuff to show you about this in > Montreal. In the mean time, maybe don't trust Whatsapp a lot ;) > > Usama > > > [0] > https://datatracker.ietf.org/meeting/123/materials/slides-123-tls-remote-attestation-with-exported-authenticators-00.pdf#page=6 > > [1] > https://datatracker.ietf.org/meeting/123/materials/slides-123-ufmrg-attested-tls-00.pdf#page=14 > > [2] > https://datatracker.ietf.org/meeting/123/materials/slides-123-rats-attested-tls-00.pdf#page=4 > > [3] > https://mailarchive.ietf.org/arch/msg/attested-tls/IYPz5RGj3WnjruWEVUzkwjH7cmQ/ > > [4] > https://mailarchive.ietf.org/arch/msg/seal/bWYv_egL7Myw_bFjeyen8CfI_fw/ > > [5] > https://datatracker.ietf.org/meeting/123/materials/chatlog-123-expat-202507211430-00 > > [6] > https://datatracker.ietf.org/doc/draft-fossati-tls-exported-attestation/ > > [7] https://mailarchive.ietf.org/arch/msg/tls/Jx_yPoYWMIKaqXmPsytKZBDq23o/ > > [8] > https://ai.meta.com/static-resource/private-processing-technical-whitepaper > > [9] > https://datatracker.ietf.org/meeting/123/materials/slides-123-ufmrg-attested-tls-00.pdf#page=26 > _______________________________________________ > 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]
