> The second working group goal is to improve protocol extensibility, > usability, and deployability, e.g., GREASE, Delegated Credentials, > Certificate Compression, and Exported Authenticators. These working group > items will include a focus on privacy properties of (D)TLS, with a particular > emphasis on the following: > > - Encrypt the ClientHello SNI (Server Name Indication) and other > application-sensitive extensions, such as > ALPN (Applications-Layer Protocol Negotiation). > - Identify and mitigate other (long-term) user tracking or fingerprinting > vectors enabled by TLS deployments and implementations. > - Consider additional privacy-preserving mechanisms, e.g., consistent > application traffic padding. > - Develop privacy-friendly profiles describing recommended usage of > (D)TLS for generic use. Protocol-specific profiles are out of scope.
[...snip...] > With these objectives in mind, the TLS WG will also place a priority in > minimizing gratuitous changes to (D)TLS. I think that last sentence is meant to prevent bright ideas from complicating---or harming---the security of TLS as defined or as implemented. But I'd like to see it as part of the second working group goal too. For example: "The second working group goal is sustain TLS' properties of confidential and authenticated communication, while also improving protocol extensibility, usability, and deployability..." The first obligation of an extension, whether it's heartbeat or key escrow, is to show that it isn't going to hurt core TLS to have it out there in the ecosystem. -Brian -- Brian Sniffen Akamai Technologies _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
