[TLS] draft-ietf-tls-tls13-19 posted

2017-03-10 Thread Eric Rescorla
I just posted draft-19 at: https://tools.ietf.org/html/draft-ietf-tls-tls13-19 This draft includes all the outstanding wire format changes that I believe we are going to make before publication (changelog below). There are three remaining issues that we need to address somehow. I've listed them

[TLS] I-D Action: draft-ietf-tls-tls13-19.txt

2017-03-10 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Eric Rescorla
Thanks On Fri, Mar 10, 2017 at 11:26 AM, Andrei Popov wrote: > It will be inelegant to have two code points for what is conceptually the > same thing, but I think this is the best option, under the circumstances. > > > > Cheers, > > > > Andrei > > > > *From:* Eric Rescorla [mailto:e...@rtfm.com]

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Andrei Popov
It will be inelegant to have two code points for what is conceptually the same thing, but I think this is the best option, under the circumstances. Cheers, Andrei From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Friday, March 10, 2017 10:53 AM To: Andrei Popov Cc: Ilari Liusvaara ; tls@ietf.or

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Eric Rescorla
On Fri, Mar 10, 2017 at 10:04 AM, Andrei Popov wrote: > Ø Does anyone use this? > > Ø I don't think anyone uses it. > > > > Au contraire: Windows TLS stack supports user_mapping and this mechanism > appears to be somewhat in use. However, I agree that this falls into the > category of extension

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Andrei Popov
Well, admittedly neither user_mapping, nor cert_type is hugely popular. It would not make sense for the TLS 1.3 spec to be on hold until these extensions are reconciled with it. However, I do think that a TLS 1.3 ClientHello should be able to advertise extensions that are not defined for TLS 1.

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Ilari Liusvaara
On Fri, Mar 10, 2017 at 06:04:54PM +, Andrei Popov wrote: > Ø Does anyone use this? > > Ø I don't think anyone uses it. > > Au contraire: Windows TLS stack supports user_mapping and this > mechanism appears to be somewhat in use. However, I agree that > this falls into the category of exten

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Andrei Popov
Ø Does anyone use this? Ø I don't think anyone uses it. Au contraire: Windows TLS stack supports user_mapping and this mechanism appears to be somewhat in use. However, I agree that this falls into the category of extensions that need to be either deprecated or redefined for TLS 1.3. Cheers

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Eric Rescorla
On Fri, Mar 10, 2017 at 9:23 AM, Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 08:42:38AM -0800, Eric Rescorla wrote: > > On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > > The problem here is, one can't do that with TLS 1.2+1.3 dual-version >

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Ilari Liusvaara
On Fri, Mar 10, 2017 at 08:42:38AM -0800, Eric Rescorla wrote: > On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara > wrote: > > > The problem here is, one can't do that with TLS 1.2+1.3 dual-version > > either. If client doesn't know what extension X means in TLS 1.3 > > (but does know it for TLS

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Eric Rescorla
On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 07:02:22AM -0800, Eric Rescorla wrote: > > On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > - user_mapping: Has extra handshake message. > > > - cert_type: All the

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Ilari Liusvaara
On Fri, Mar 10, 2017 at 07:02:22AM -0800, Eric Rescorla wrote: > On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara > wrote: > > > - user_mapping: Has extra handshake message. > > - cert_type: All the problems of CCertT and SCertT, combined with > > fixing both to be the same. > > > > Does anyon

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

2017-03-10 Thread Russ Housley
Thanks. I agree. I think that the existing text is more helpful to the implementer. If the details of the analysis do in the document, it should be in the security considerations. Russ > On Mar 9, 2017, at 9:18 PM, Sean Turner wrote: > > After many emails about the wording for s5.5 Limits

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Viktor Dukhovni
> On Feb 7, 2017, at 11:12 AM, Ben Schwartz wrote: > > Like a lot of people here, I'm very interested in ways to reduce the leakage > of users' destinations in the ClientHello's cleartext SNI. It seems like the > past and current proposals to fix the leak are pretty difficult, involving a >

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Eric Rescorla
On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara wrote: > On Thu, Mar 09, 2017 at 04:43:19PM -0800, Eric Rescorla wrote: > > As noted in https://github.com/tlswg/tls13-spec/issues/722, the new > fancy > > TLS 1.3 Certificate structure doesn't map well to the various non-X.509 > > cert structures

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Ilari Liusvaara
On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote: > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficu

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Ryan Sleevi
On Fri, Mar 10, 2017 at 7:33 AM Martin Rex wrote: > CABrowser-Forum defines the rules which browsers implemenent on > top of rfc2818 section 3.1 server endpoint identity checks > of server certificates. This is neither accurate nor correct. The CA/Browser Forum neither describes nor dictates br

Re: [TLS] Updating for non-X.509 certificate types

2017-03-10 Thread Ilari Liusvaara
On Thu, Mar 09, 2017 at 04:43:19PM -0800, Eric Rescorla wrote: > As noted in https://github.com/tlswg/tls13-spec/issues/722, the new fancy > TLS 1.3 Certificate structure doesn't map well to the various non-X.509 > cert structures we have defined, specifically: > > - Raw Public Keys > - Cached Inf

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Martin Rex
Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote: >> >> You don't understand the purpose of SNI and how the (already weak) >> rfc2818 section 3.1 server endpoint identification and CABrowser Forum >> public CA Domain validation has been designed to work. > > SNI

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Ilari Liusvaara
On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote: > > You don't understand the purpose of SNI and how the (already weak) > rfc2818 section 3.1 server endpoint identification and CABrowser Forum > public CA Domain validation has been designed to work. SNI has extremely little to do with

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

2017-03-10 Thread Martin Rex
Ben Schwartz wrote: > Martin Rex wrote: > >>Ben Schwartz wrote: >>> >>> Like a lot of people here, I'm very interested in ways to reduce the >>> leakage of users' destinations in the ClientHello's cleartext SNI. It >>> seems like the past and current proposals to fix the leak are pretty >>> diff