Re: [TLS] how close are we?

> On Oct 11, 2016, at 23:21, Peter Gutmann wrote: > > Xiaoyin Liu writes: > >> Not directly related to Rich's question, but will we settle the "TLS 1.3 -> >> TLS 2.0" >> discussion (PR #612) before WGLC? Or has this already been closed as

Re: [TLS] how close are we?

Xiaoyin Liu writes: >Not directly related to Rich's question, but will we settle the "TLS 1.3 -> >TLS 2.0" >discussion (PR #612) before WGLC? Or has this already been closed as "keeping >the current name"? The impression I got from the discussion was that most people,

Re: [TLS] Finished stuffing/PSK Binders

Thanks, I'll look at this. I'll be merging this change (modulo your comments) Friday unless there is significant objection. -Ekr On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson wrote: > On 12 October 2016 at 00:51, Eric Rescorla wrote: > > See: > >

Re: [TLS] how close are we?

I've got a bunch of PRs in flight that I think we need to resolve one way or the other. I'm expecting the chairs to address those shortly and if all goes well with that I'll put out -17 next week and then we should revisit this question. Best, -Ekr On Tue, Oct 11, 2016 at 7:23 PM, Salz, Rich

Re: [TLS] how close are we?

Not directly related to Rich's question, but will we settle the "TLS 1.3 -> TLS 2.0" discussion (PR #612) before WGLC? Or has this already been closed as "keeping the current name"? Best, Xiaoyin From: TLS

[TLS] how close are we?

I've been away, and sick, for most of the post three weeks. How close is this ready to WGLC? Is it really just polishing the shiny bits? I mean I can kinda understand that, but also parts of this seems like lsat-midnight late-night hacking. Looking for some input here. -- Senior Architect,

Re: [TLS] Finished stuffing/PSK Binders

On 12 October 2016 at 00:51, Eric Rescorla wrote: > See: > https://github.com/tlswg/tls13-spec/pull/678 I'm convinced that this is the right change. Reconstruction was always going to be brittle. I will note that I don't think that the change gets the error codes right though.

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

There are a couple of scenarios we need to keep in mind: 1. Existing HTTP/1.1 exchanges over upgraded TLS clients. If we need a brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 1.3, that’s fine. 2. Client authentication in HTTP/2. Slightly longer

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

+ Mike who has additional concerns with this. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Tuesday, October 11, 2016 10:22 AM To: Hannes Tschofenig Cc: tls@ietf.org Subject: Re: [TLS] Making post-handshake messages optional

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

The major thing that this proposal achieves is that it makes post-handshake auth an optional part of the implementation. Instead of this, I would also be in favor of a simpler change that modifies the text to say that post-handshake CertificateRequest messages are fatal by default and only

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for specific application profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC). Here is a PR for this: https://github.com/tlswg/tls13-spec/pull/680 Andrei, would this cause you any problem? My

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

Hi Nick, given my discussion with Martin in this thread https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like your idea of making the post-handshake messages optional since it allows me to develop a TLS 1.3 client that is smaller in code size. Ciao Hannes On 10/08/2016 03:03

Re: [TLS] Zero-RTT Data & PSK

This LGTM. Absent objections I will merge tomorrow On Tue, Oct 11, 2016 at 9:22 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > I gave it a try, see > https://github.com/tlswg/tls13-spec/pull/668/commits/ > 91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245 > > > Ciao > Hannes > > > On

Re: [TLS] Zero-RTT Data & PSK

I gave it a try, see https://github.com/tlswg/tls13-spec/pull/668/commits/91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245 Ciao Hannes On 10/10/2016 11:59 PM, Eric Rescorla wrote: > I agree with MT. Hannes, if you want to clean up the text to take into > account MT's comments, I will merge > > On

Re: [TLS] Finished stuffing/PSK Binders

On Sun, Oct 9, 2016 at 7:10 AM, Eric Rescorla wrote: > > > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: >> > After the discussion on PR #615, I took another pass at this with

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

On 8 October 2016 at 11:54, Eric Rescorla wrote: > I could go either way on this. It seems like this pushes complexity from the > client to the server. > > Consider the case of NST. Presently, a client which doesn't want resumption > can just ignore NST, > but in your proposed

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

On 11 October 2016 at 14:30, Benjamin Kaduk wrote: > So, on the balance, I think I'm starting to lean against this specific > proposal and more towards the text changes that David wants. Yes, I would rather not take NST or KU out of the mandatory set of 1.3 features. I'm

Re: [TLS] Application layer interactions and API guidance

On 11 October 2016 at 07:57, Kyle Rose wrote: > FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin > that the web is substantially broken without retry logic in the browsers, > that naturally make application-level replay mitigation a necessity. But I >