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

[Stephen Farrell <[e-mail]>]

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