Hi Wei, On 13.04.26 11:30, Wei Wang wrote:
At a high level, I think it may be helpful to take a step back and approach this from a /security-first/ perspective rather than a /design-first/ perspective. I understand this sounds like moving back to zero, but if you want me to help you, we need to move more logically and it might really help. However, I want to be clear that the final design /may/ come out to be completely different from what you have.You may be right, but in my experience, this approach has the potential of doing a lot of extra work because sometimes you find out that the whole design was not worth the effort to achieve the desired security goals. This is exactly what happened in the case of draft-fossati-tls-attestation (see [6]), and I really wouldn't like to repeat that. When the authors are attached to a specific design without consideration of security, it is very hard for me to help. So, I sincerely apologize I cannot help you any further on your specific design.[WW]: Our original intention in proposing this technical solution is to address business issues and, on that basis, examine whether any new security problems have arisen. It does not focus on security issues, so I think a design-first perspective is more suitable.
If you change your mind, please feel free to reach out to me in the future.In any case, I am happy to update guidance [4,5] in the draft, so that you can continue your work.
So based on [2], please remove 4xChangeCipherSpec from the handshake. Before proceeding with the design, I propose to first focus on the threat model and security goals (see below) to help me understand what you want to achieve.[WW]: Done.
Thank you.
Even for design-first approach, you know the keys which are used in the design, no? Elaborating what you find challenging will help me understand what kind of guidance will be helpful for you. Think of something like:What do you think? Are you open to this approach? [WW]: Thank you for the detailed explanation and the references. I find drafting the Threat Model quite challenging,
* What an attacker can do? * What can go wrong? etc. Does that help?
but I have attempted to list some Informal Security Goals in Section 7.2. Could you please review them and help us further refine the content of both Section 7.1 and Section 7.2 based on this?
This seems to be going in the right direction. Best wishes, -Usama
[6] https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS[0] https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html#section-1.3-2.6.1 [1] https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html [2] https://github.com/tlswg/tls13-spec/issues/1413 [3] https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-02.html#section-4.3[4] https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-03.html#section-5.2[5] https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-03.html#section-5.3
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
