Thanks to everyone who provided feedback on the draft charter! It’s all been incorporated in the version on GitHub [1]. We’ll work with Ben in moving this to the next step.
Thanks, Chris, on behalf of the chairs [1] https://github.com/tlswg/wg-materials/blob/master/charter/charter.md On Mon, Jan 20, 2020, at 1:55 PM, Eric Rescorla wrote: > LGTM > > On Thu, Jan 16, 2020 at 7:32 PM Christopher Wood <c...@heapingbits.net> wrote: > > Hi folks, > > > > As discussed in Singapore, it's time to re-charter the working group to > > reflect ongoing (e.g., Exported Authenticators and Encrypted SNI/CH) and > > future work (e.g., cTLS). For reference, the current charter is available > > here: > > > > https://datatracker.ietf.org/doc/charter-ietf-tls/ > > > > A draft of the new charter is below, and also available on GitHub [1]. > > Please have a look and and send comments, either here on the mailing list > > or in the GitHub repo, by 2359 UTC on 30 January 2020. Any and all feedback > > is welcome! We would like to complete this in advance of IETF 107 so we can > > move forward with items such as cTLS. > > > > ~~~ > > 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], v1.2 [RFC6347], and v1.3 > > [draft-ietf-tls-dtls13], as well as extensions to the protocols and > > ciphersuites. > > > > The working group aims to achieve three goals. First, improve the > > applicability and suitability of the TLS family of protocols for use in > > emerging protocols and use cases. This includes extensions or changes that > > help protocols better use TLS as an authenticated key exchange protocol, or > > extensions that help protocols better leverage TLS security properties, > > such as Exported Authenticators. Extensions that focus specifically on > > protocol extensibility are also in scope. This goal also includes protocol > > changes that reduce the size of TLS without affecting security. Extensions > > that help reduce TLS handshake size meet this criteria. > > > > The second working group goal is to improve security, privacy, and > > deployability. This includes, for example, Delegated Credentials, Encrypted > > SNI, and GREASE. Security and privacy goals will place emphasis on the > > following: > > > > - Encrypt the ClientHello SNI (Server Name Indication) and other > > application-sensitive extensions, such as ALPN (Application-Layer Protocol > > Negotiation). > > - Identify and mitigate other (long-term) user tracking or fingerprinting > > vectors enabled by TLS deployments and implementations. > > > > The third goal is to maintain current and previous version of the (D)TLS > > protocol 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 goals in mind, the working group will also place a priority in > > minimizing gratuitous changes to (D)TLS. > > ~~~ > > > > Best, > > Chris, on behalf of the chairs > > > > [1] https://github.com/tlswg/wg-materials/blob/master/charter/charter.md > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
