Re: [TLS] kicking off charter revision discussion
On Tue, Oct 30, 2018 at 09:53:47PM -0400, Sean Turner wrote: > > On Oct 30, 2018, at 17:41, Nico Williams wrote: > > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > >> 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. > > 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. > > Should the DANE DNSSEC chain extension be on the charter? We do need to > > finish it. > > 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 -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] kicking off charter revision discussion
> On Oct 30, 2018, at 17:41, Nico Williams wrote: > > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: >> 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. 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. >> [...] >> >> 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] kicking off charter revision discussion
On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > 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 -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] kicking off charter revision discussion
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 , wrote: > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
