Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

2016-10-08 Thread John Mattsson
Hi Martin, AES_256_CCM_8 was not in the first versions of the draft but added later after request from IoT people (probably afraid of quantum computers). While I think it makes very much sense to have short tags in wireless radio, I do not know how large need there is for AES-256 in IoT for c

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

2016-10-08 Thread Eric Rescorla
I agree that this is a good idea. Absent objection, i'm going to merge this PR on Monday On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin wrote: > We were also expecting to want to bound how much traffic a server could be > compelled to skip over without making progress. It actually didn't occur t

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

2016-10-08 Thread Nick Sullivan
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 connectio

Re: [TLS] Application layer interactions and API guidance

2016-10-08 Thread David Benjamin
To add to that, in out-of-order transports, whether a message was sent over 0-RTT or not may not even be very well-defined. If QUIC originally sent data over 0-RTT but had to retransmit it after the full connection parameters are available, I believe it will use those. Even in an in-order transpor

Re: [TLS] Application layer interactions and API guidance

2016-10-08 Thread Eric Rescorla
On Sat, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara wrote: > On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote: > > > > In the APIs people have been designing, 0-RTT can become 1-RTT but not > the > > other way around. > > Specifically: > > > > - There is an option to allow 0-RTT writing

Re: [TLS] Application layer interactions and API guidance

2016-10-08 Thread Ilari Liusvaara
On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote: > > In the APIs people have been designing, 0-RTT can become 1-RTT but not the > other way around. > Specifically: > > - There is an option to allow 0-RTT writing > - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT mo

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

2016-10-08 Thread Eric Rescorla
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)

2016-10-08 Thread Ilari Liusvaara
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, if

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

2016-10-08 Thread David Benjamin
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 CertificateReques

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

2016-10-08 Thread Nick Sullivan
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] Application layer interactions and API guidance

2016-10-08 Thread Eric Rescorla
On Sat, Oct 8, 2016 at 7:25 AM, Watson Ladd wrote: > On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote: > > > > > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > >> > >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > >> > On Fri, Sep

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

2016-10-08 Thread David Benjamin
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 > attempt to make the story m

Re: [TLS] Application layer interactions and API guidance

2016-10-08 Thread Watson Ladd
On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara > wrote: >> >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: >> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara >> > wrote: >> > > >> > > Also, it is very likely that 0-R

Re: [TLS] Application layer interactions and API guidance

2016-10-08 Thread Ilari Liusvaara
On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > wrote: > > > > > > > > Also, it is very likel

Re: [TLS] Finished stuffing/PSK Binders

2016-10-08 Thread Ilari Liusvaara
On Fri, Oct 07, 2016 at 01:41:48PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote: > > > On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > > wrote: > > > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700,

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

2016-10-08 Thread Ilari Liusvaara
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 > attempt to make the story more explicit by adding a new post_handshake > extension