Re: [TLS] sslkeylogfile

[Martin Thomson <[e-mail]>]

Thanks for the input John,

I agree on both points, the minor one and the substantive one.

https://github.com/martinthomson/sslkeylogfile/pull/1  is my attempt to put something stronger about usage/applicability up front.  Do you think that is sufficient?

On Thu, Nov 24, 2022, at 21:37, John Mattsson wrote:
> Hi,
> 
> Two high level comments:
>
>
> - OLD: "though use of earlier versions is strongly discouraged [RFC8996]"
> 
> That is not what RFC 8996 says. RFC 8996 says
> 
> - "TLS 1.1 MUST NOT be used."
> - "TLS 1.1 MUST NOT be used."
> 
> Please change to something that aligns with RFC 8996 such as
> 
> NEW: "though use of earlier versions is forbidden [RFC8996]"
> 
> 
> -  "Access to the content of a file in SSLKEYLOGFILE allows an attacker
>    to break the confidentiality protection on any TLS connections that
>    are included in the file."
> 
> This is true but does not at all reflect the implications of the 
> existence of a file for long-term storage of keys like this. Storing 
> any of the keying material like this completely breaks the stated 
> forward secrecy property of TLS 1.3 as it creates new long-term keys. 
> It does not matter how well the file is protected i.e.,
> 
>    "Ensuring adequate access control on these files therefore becomes
>    very important."
> 
> is not enough. The theoretical security properties are still broken 
> badly. I think this draft is problematic, but I can understand the need 
> to standardize this existing format. I think the fact that 
> SSLKEYLOGFILE breaks the security properties of TLS 1.3 needs to very 
> clearly described. As a consequence, I think the only allowed use case 
> standardized by TLS WG should be limited to non-production debugging. 
> If governments and companies wanting visibility do other things, that 
> would be outside of IETFs control.