With the finalization of TLS 1.3 behind us, it is time to consider rechartering 
the working group to address ongoing and emerging issues in this space. Below 
is a proposal for the new charter text to get this discussion going before we 
meet in Bangkok. We plan to have a 20 minute discussion section on the charter 
in one of the upcoming TLS WG meeting sessions. If you have objections to what 
is written, please raise them to the list; we will track them with issues in 
the newly created GH repo [0]. If you feel something is omitted, please also 
bring it to the list but also feel free to suggest edits via issues/PRs in that 
repo.

Thanks,
Chris, Joe, and Sean

[0]  https://github.com/tlswg/wg-materials/tree/master/charter. 

Proposed Charter Text

The TLS (Transport Layer Security) working group was established in 1996 to 
standardize a 'transport layer' security protocol. The basis for the work was 
SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a 
series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 
[RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 
[RFC4347] and v1.2 [RFC6347], as well as extensions to the protocols and 
ciphersuites.

The working group aims to achieve three goals. First, to develop DTLS 1.3, in a 
way that draws upon the design, analysis, and engineering effort put into TLS 
1.3. Specifically, the protocol should exhibit the following features, in no 
particular order: 

- Encrypt as much of the handshake and datagram packets as
  possible to reduce the amount of observable data to both
  passive and active attackers.
- Reduce handshake latency and aim for one roundtrip for a full
  handshake and one or zero roundtrip for repeated handshakes
  without compromising current security features.
- Use cryptographic algorithms equivalent to those used in TLS 1.3.

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. 

The third goal is to maintain current and previous version of the (D)TLS 
protocols as well as to specify general best practices for use of (D)TLS, 
extensions to (D)TLS, and cipher suites. This includes recommendations as to 
when a particular version should be deprecated. Changes or additions to older 
versions of (D)TLS whether via extensions or ciphersuites are discouraged and 
require significant justification to be taken on as work items. 

With these objectives in mind, the TLS WG will also place a priority in 
minimizing gratuitous changes to (D)TLS.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to