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

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls