I think we should abandon this effort and not publish.
When initially proposed this was supposed to be documenting a deployed reality. I could just about hold my nose with that, but adding in ECH (for which key exfiltration is not currently deployed, nor seemingly needed) and the IANA considerations make this much more unacceptable. While I expected to be in the rough for the initial proposal I do hope others find this as unacceptable as I do and we don't publish. Including ECH here is IMO not necessary - there is no history of needing that for debugging purposes so adding it based on speculation is IMO wrong and a fatal error. This is now extensible (via IANA specification required) which is a problem as that means anyone can likely define new ways to exfiltrate secrets from TLS implementations without any WG overview. That IMO is another fatal error. Less importantly, but still substantively, the draft does not, but should, recommend that this feature only be available via conditional compilation (where available) and not be part of any standard library or other release. If publishing, we should be aiming for the strongest possible implementation guidance in that respect. Thanks, S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
