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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
