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
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
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]
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
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
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.
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
Ø 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
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
>
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
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
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
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
> 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
>
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
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
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
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
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
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
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
21 matches
Mail list logo