On 15/03/2024 03:43, Martin Thomson wrote:
Reasonable statement. It's a variation on what we already have, but the focus on forward secrecy is worth a small paragraph: How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files
I think that's a good addition (with or without Dennis's comment). Thanks, S.
On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote:I have a suggestion which keeps things technical but hopefully addresses Stephen's concern: In Security Considerations: "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it records the used session key and so invalidates many of the security claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred data does not benefit from the security protections offered by RFC 8446 and systems using SSLKEYLOGFILE cannot be considered compliant with RFC 8446 or offering similar security to the protocol outlined in that draft." I don't think the wording there is quite right, but I do think the Security Considerations should clearly call out the impact on forward secrecy and RFC 8446 in general and so dissuade use. Best, Dennis On 12/03/2024 23:07, Eric Rescorla wrote:On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote:Sorry also for a late suggestion, but how'd we feel about adding some text like this to 1.1? "An implementation, esp. a server, emitting a log file such as this in a production environment where the TLS clients are unaware that logging is happening, could fall afoul of regulatory requirements to protect client data using state-of-the-art mechanisms."I agree with Ekr. That risk is not appreciably changed by the existence of a definition for a file format.I totally do consider our documenting this format increases the risk that production systems have such logging enabled, despite our saying "MUST NOT." So if there's a way to further disincentivise doing that, by even obliquely referring to potential negative consequences of doing so, then I'd be for doing that.Aside from this particular case, I don't think technical specifications should "obliquely" refer to things. Technical specifications should be clear. -EkrHence my suggestion. S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
