> Step0: we have this existing deployed thing we want to document. As I wrote in [1], republishing without adding considerations and guard rails is already bad.
> I think it is an interesting idea to use the KEYLOG format to help > debugging of other security protocols. I think easy debugging helps > deployment of security protocols. > Step1: hey can I add ECH to that? > Step2: let's allow a DE to extend the set of keys we exfiltrate I think this is another boundary being crossed. There are two things to debug: The security protocol implementation, and the implementation of the application protocol running on top of it. I am not convinced that the security protocol implementation even needs debugging in a standardized form. After all, if you are debugging TLS (or whatever), you can see that protocol being used on the wire. If you do not fully understand a bug in your implementation, why would you expect it to output any kind of helpful keying material? Why would that be more helpful than an ad hoc debugging method in your implementation? This also goes for ECH, which is part of TLS, not the application layer. Maybe it is worth it to limit the scope of extractable keys to encryption keys, such that application protocols and their implementations can be debugged. With each increase in scope, I fear we might be even less able to formulate resonable security considerations other than "If you implement this, you are more likely to be doomed". > Step3: let's do the same for more protocols Putting aside EDHOC, the main LI-usecase here is S/MIME and PGP, i.e. widely deployed protocols among users. I do not see much debugging need in these protocols except for TLS. There are seldomly new protocols based on S/MIME. For this reason, it does not seem worth it to include them. As for EDHOC, I am not sure the security considerations change much going from one secure transport to another. Could non-standardization drive people from EDHOC to TLS? > Step4: I need to centralise all those key logs > Step5: We have a standard for cross-protocol LI LI somewhere on the server side should not matter too much here. After all, any company or administrator forced by law to exfiltrate their traffic will find a convenient way to do so, even if it just means to turn off TLS between servers, or installing a TLS-terminating proxy and running LI-software behind that. Software should still emit a (possibly standardized and easy to find?) warning in the logs somewhere. LI on the user's device is another deal. Again, at a minimum the user should be warned as I mentioned in [2]. We do not need to prevent LI here (and can't). We just need to make sure the situation is not worsened by a key file format. -- TBB [1] https://mailarchive.ietf.org/arch/msg/tls/FWmfouytzzqMb614Jv4y1cJxTqc/ [2] https://mailarchive.ietf.org/arch/msg/tls/nnqmXWtuBUD7W5NOkB57BYk723c/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
