Re: [TLS] Working Group Last Call for SSLKEYLOG File

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.farrell@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