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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
