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

Even without the Finished computation, rejecting a CertificateRequest would hit the same unboundedness problem the previous generation of KeyUpdate had. Our implementation currently treats all post-handshake CertificateRequests as a fatal error. I think the only context where we'd conceivably

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

On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote: > > I don't think it's too much to ask that implementations be able to > reject a post-handshake CertificateRequest gracefully, even if they have > no intention of ever implementing a proper Client Certificate response.

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

On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > 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

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

x.net>> Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: 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

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 <hannes.tschofe...@gmx.net> Cc: tls@ietf.org Subject: Re: [TLS] Making post-handshake messages op

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] 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] Making post-handshake messages optional in TLS 1.3 (#676)

With respect to communicating policy from the application layer to the TLS stack, what's wrong with David's "CertificateRequest is disallowed by default, and the application must make a library call to enable it for a given connection/context" proposal? It seems fairly straightforward in terms of

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

I agree that "I don't like NST or KU" is not a very useful thing to add to the spec. I added them as part of a general move towards clarity and conservatism about which types of post-handshake messages are permissible in TLS 1.3. Right now the spec is ambiguous about what each side of the

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

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 change, the server needs to read this extension and then conditionally send NST,

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

On Sat, Oct 08, 2016 at 04:32:32PM +, Nick Sullivan wrote: > I'm not proposing any new post-handshake authentication mechanisms or > anything relating to HTTP/2 renegotiation in this change. I'm simply making > support for the existing post-handshake messages optional. > > With this change,

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

Right, but making it an extension does not really capture the complexities of post-handshake auth. What's needed is mostly spec text, not wire changes. The text should say something to the effect of unexpected CertificateRequests are always fatal to the connection. By default, all

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

I'm not proposing any new post-handshake authentication mechanisms or anything relating to HTTP/2 renegotiation in this change. I'm simply making support for the existing post-handshake messages optional. With this change, if the client does not opt in, unexpected CertificateRequests are fatal to

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

On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara wrote: On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an >

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

There has been a lot of discussion lately about post-handshake messages that do not contain application data and how to handle them. This PR is an attempt to make the story more explicit by adding a new post_handshake extension to TLS 1.3. Supporting all types of post-handshake messages can