Subject: [TLS] Re-chartering TLS

From: "Christopher Wood" <[email-masked]>
Date: Thu, 16 Jan 2020 19:31:35 -0800

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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 17 Jan 2020 09:39:20 +0300

Dear Christopher,

On Fri, Jan 17, 2020 at 6:32 AM Christopher Wood <[email-masked]>
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:
>
> 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.
>

I think it's worth replacing "the size" with "the resource consumption" in
the description of this goal. Otherwise, the tls-batch-signing draft (
https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/) may be
left out of the scope of the charter.

-- 
SY, Dmitry Belyavsky

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 17 Jan 2020 05:54:31 -0800

On Thu, Jan 16, 2020, at 10:39 PM, Dmitry Belyavsky wrote:
> I think it's worth replacing "the size" with "the resource consumption" 
> in the description of this goal. Otherwise, the tls-batch-signing draft 
> (https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/) 
> may be left out of the scope of the charter.

Good suggestion -- thanks!

Best,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 18 Jan 2020 17:19:00 +0000

I'd remove "With these goals in mind" from the last sentence, but the new charter (with the "resources" edit) even if my suggestion isn't accepted.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Sat, 18 Jan 2020 18:29:50 +0100

LGTM, I agree with using “resource" instead of “size”…
My understanding is that “security” is broad enough to cover new authentication mechanisms
and that “privacy" will be broad enough to cover “metadata protection” if needed, correct?
B.

> On Jan 17, 2020, at 4:31 AM, Christopher Wood <[email-masked]> wrote:
> 
> Hi folks,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 18 Jan 2020 10:17:04 -0800

On Sat, Jan 18, 2020, at 9:19 AM, Salz, Rich wrote:
> I'd remove "With these goals in mind" from the last sentence, but the 
> new charter (with the "resources" edit) even if my suggestion isn't 
> accepted.

To confirm, you'd replace this:

 "With these goals in mind, the working group will also place a priority in minimizing gratuitous changes to (D)TLS."

with this:

  "The working group will also place a priority in minimizing gratuitous changes to (D)TLS."

Right? That seems fine to me!

Thanks,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 18 Jan 2020 10:17:30 -0800

> and that “privacy" will be broad enough to cover “metadata protection” 

Indeed -- that's the intent! 

Best,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 18 Jan 2020 18:26:21 +0000

>    Right? That seems fine to me!
  
Great, thanks.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 13:55:22 -0800

LGTM

On Thu, Jan 16, 2020 at 7:32 PM Christopher Wood <[email-masked]>
wrote:

> 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.
>

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 31 Jan 2020 08:36:11 -0800

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,

On Mon, Jan 20, 2020, at 1:55 PM, Eric Rescorla wrote:
> LGTM
> 
> On Thu, Jan 16, 2020 at 7:32 PM Christopher Wood <[email-masked]> wrote:
> > Hi folks,
> >