Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On 28/01/2019 21:18, Kurt Roeckx wrote: > On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote: >> >> >> On 24/01/2019 18:12, Sam Roberts wrote: >>> The other changes that TLS1.3 requires, multiple session tickets, a >>> few new APIs to replace some of the SSL_renegotiate use-cases,

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote: > > > On 24/01/2019 18:12, Sam Roberts wrote: > > The other changes that TLS1.3 requires, multiple session tickets, a > > few new APIs to replace some of the SSL_renegotiate use-cases, etc., > > all are pretty routine. We could get

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On 24/01/2019 18:12, Sam Roberts wrote: > The other changes that TLS1.3 requires, multiple session tickets, a > few new APIs to replace some of the SSL_renegotiate use-cases, etc., > all are pretty routine. We could get TLS1.3 support in Node.js fairly > quickly if the info callback issue was

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

I appreciate that there are multiple ways of looking at this, but I don't think that looking at the info callback from the point of view of "is it or is it not a handshake record" is pragmatic. The SSL_set_msg_callback could be used by people wanting to see all the underlying records. The way the

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On Thu, Jan 24, 2019 at 9:45 PM Matt Caswell wrote: > > This notion of "handshake" is not supported by RFC 8446 uses the terms > "the > > handshake", "a handshake", and "post-handshake". "Post-handshake", in > > particular, implies KeyUpdate are after the handshake, not part of it. > > I just

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On 23/01/2019 18:29, Viktor Dukhovni wrote: > I should also note that there are two > issues in this thread, of which this is the second. The first one is about > the limit on the number of key update messages per connection, and I hope > that we can do something sensible there with less

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

> On Jan 23, 2019, at 12:42 PM, David Benjamin wrote: > > (a) Debugging hooks for tracing, often copied from the openssl binary. > (b) As a callback to know when the handshake (in the RFC8446 sense described > above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE. > (c) As a

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell wrote: > On 22/01/2019 20:41, David Benjamin wrote: > > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni < > openssl-us...@dukhovni.org > > > wrote: > > As for applications mishandling "SSL_CB_HANDSHAKE_START",

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On 22/01/2019 20:41, David Benjamin wrote: > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > wrote: > > > > > On Jan 22, 2019, at 2:06 PM, Adam Langley > wrote: > > > > (This is another installment of our

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote: > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > what to do there, but perhaps we could define a new even for keyUpdates > that does not mislead applications into assuming a new "handshake". I think

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

> On Jan 22, 2019, at 2:06 PM, Adam Langley wrote: > > (This is another installment of our experiences with deploying the > RFC-final TLS 1.3—previous messages: [1][2]. We share these with the > community to hopefully avoid other people hitting the same issues.) > > [...] > > However,