[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

[Ilari Liusvaara <[e-mail]>]

On Tue, Feb 25, 2025 at 12:01:00PM +0000, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 24/02/2025 21:54, Martin Thomson wrote:
> > but
> > this is a case where that interoperation already exists.
> I think the above was true of your initial draft Martin,
> but is significantly less true of the current draft that
> includes an IANA registry setup with the specification
> required procedure - that, in addition to the addition of
> ECH exfiltration, means that publishing this implies that
> the TLS WG approve of whatever methods of exfiltration a
> DE approves of, and that we approve of every new thing we
> add to TLS (ECH in the current case) having an exfiltration
> method defined for it, without WG oversight.

This is an application debugging tool. ECH adds new keys that need to
be exported for application debugging purposes (as the ECH may contain
application-specific extensions).

TLS extensions are already specification required. Bad extensions can
do stuff that is absolutely fatal to security (way beyond any even
remotely reasonable SSLKEYLOG key type). And moreover, those extensions
may introduce new keys that need to be exported for application
debugging (just like ECH does).

And extensions are not the only specification required registry where
bad stuff can be absolutely fatal (cipher suites and supported groups
are the most obvious examples).

Moreover, the very purpose of Specification Required / DE is to not
have WG approval of every thing added. So if WG oversight is needed
for actions with major potential security impact, those three
registeries need to have policies changed. RFC 8447 explicitly states
that changing extensions and ciphersuites to Specification Required
was WG consensus.




-Ilari