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 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. >> >> -Ekr >> >>> Hence 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
