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

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

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

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

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] Application layer interactions and API guidance

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

Re: [TLS] Application layer interactions and API guidance

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

Re: [TLS] Application layer interactions and API guidance

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

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] Application layer interactions and API guidance

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

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 >

Re: [TLS] Application layer interactions and API guidance

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 >> >