Subject: [TLS] kicking off charter revision discussion

From: Sean Turner <[email-masked]>
Date: Wed, 24 Oct 2018 20:19:33 -0400

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.

---

From: William Whyte <[email-masked]>
Date: Mon, 29 Oct 2018 07:34:52 -0700

I’m happy to submit the draft as it stands. I think it’s covered by the recharter below under “maintain” the spec, though perhaps we should suggest that this is changed to “maintain and, as necessary, extend”.

Cheers,

William
On Oct 24, 2018, 8:20 PM -0400, Sean Turner <[email-masked]>, wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Brian Sniffen <[email-masked]>
Date: Tue, 30 Oct 2018 10:59:51 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 16:41:48 -0500

> Proposed Charter Text

+1, but see comments below.

First off, suppose we wanted to write a successor to RFC2712 for TLS
1.3, should we pursue that in the TLS WG, or KITTEN WG?  I'm amenable to
either, and even both.

> [...]
>
> 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:

Should the DANE DNSSEC chain extension be on the charter?  We do need to
finish it.

> [...]

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Tue, 30 Oct 2018 21:53:47 -0400

> On Oct 30, 2018, at 17:41, Nico Williams <[email-masked]> wrote:
> 

I think both would be bad, but whether it goes in one or the other would come down to whether there are enough people interested in doing the work.

> Should the DANE DNSSEC chain extension be on the charter?  We do need to

In the current charter, we already have generic text about extensions and no specific text about the DANE DNSSEC draft though we adopted the draft and there is a milestone for it.  I prefer not to list every draft we are working on in the charter specifically because then we have to change the darn charter every time we want to adopt a draft.

We are going to spend a lot of time discussing the DANE DNSSEC draft.  When it gets done and what is in it is certainly up for discussion.

spt

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 23:11:53 -0500

On Tue, Oct 30, 2018 at 09:53:47PM -0400, Sean Turner wrote:
> I think both would be bad, but whether it goes in one or the other
> would come down to whether there are enough people interested in doing
> the work.

OK.  I suspect we can get it done in KITTEN WG, where we have the
Kerberos expertise, as it's really just a use of PSK in TLS, so we'd not
need to extend TLS in any way.  I think most here would agree.

> In the current charter, we already have generic text about extensions
> and no specific text about the DANE DNSSEC draft though we adopted the
> draft and there is a milestone for it.  I prefer not to list every
> draft we are working on in the charter specifically because then we
> have to change the darn charter every time we want to adopt a draft.

Just making sure!

> We are going to spend a lot of time discussing the DANE DNSSEC draft.
> When it gets done and what is in it is certainly up for discussion.

Indeed.

Thanks,

Nico
--