Re: [TLS] Improved nonce generation method for TLS 1.3

On Fri, Jun 02, 2017 at 03:33:46PM -0700, Andrey Jivsov wrote: > The motivation for this is stronger separation between the encryption > layer and the TLS layer. An alignment with FIPS 140 guidance is another > motivation, which tells that the IV management shall be internal (in > encryption direct

Re: [TLS] Improved nonce generation method for TLS 1.3

Regarding [2], we should be counting the functionality for serialization and the increment of record number needed by the current nonce method. Serialization would need two bswaps for little-endian platforms and an increment. (We need to bring the integer into host format first, thus the roundtrip

Re: [TLS] Improved nonce generation method for TLS 1.3

It's worth noting that we considered a variant of this design initially and then decided on the XOR design instead. -Ekr On Fri, Jun 2, 2017 at 4:20 PM, Adam Langley wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov wrote: > >> The benefits are that the encryption layer doesn't need to d

Re: [TLS] Improved nonce generation method for TLS 1.3

On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov wrote: > The benefits are that the encryption layer doesn't need to deal with a > record number or its serialization, or the mask. The state is minimal. > The nonce update code is faster and smaller (e.g. 3 instructions on > x86_64). > > I would like

[TLS] Improved nonce generation method for TLS 1.3

Greetings. I would like to suggest a small tweak to the nonce generation method in TLS 1.3. The motivation for this is stronger separation between the encryption layer and the TLS layer. An alignment with FIPS 140 guidance is another motivation, which tells that the IV management shall be interna

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote: > I've just gone through this thread and I'm having a very hard time > understanding what the actual substantive argument is about. > I believe at this point we mostly disagree on what specific scenarios are and are not a concern that should b

Re: [TLS] Security review of TLS1.3 0-RTT

> > On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla wrote: > > > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > >connection failures) then a DKG-style attack where the client > >replays the 0-RTT data in 1-RTT is possible. > > > > This isn't what I call a replay. It's a seco

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 03:28:33PM +0200, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then it > > > can of course not > > > expect not to get blacklisted across services. Is it not alre

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then > it > > > can of course not > > > expect not to get blacklisted across services. Is it not already co

Re: [TLS] Security review of TLS1.3 0-RTT

It's still there, in 4.6.1. "The sole extension currently defined for NewSessionTicket is “early_data”, indicating that the ticket may be used to send 0-RTT data (Section 4.2.9 )). It contains the following value:" -Ekr On Fri, Jun 2, 2

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > If a web service hoster does not provide any useful demultiplexer then it > > can of course not > > expect not to get blacklisted across services. Is it not already common > > practice to assign > > separate certificates to separate "

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > > Operators trying to do this by inspecting TLS (and not decrypting) are > > going to have a bad time anyway. With HTTP/2 connection coalescing, even > > if they can see the

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > Operators trying to do this by inspecting TLS (and not decrypting) are > going to have a bad time anyway. With HTTP/2 connection coalescing, even > if they can see the certificate, the actual HTTP request could be for any > name in

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in > the clear as

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 10:43:00AM +0200, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in the

Re: [TLS] Encrypted SNI

Thanks, Benoit [hope it's ok. to cross-port and redirect replies to TLS] I have not followed TLS 1.3 in detail, so a quick question first: Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or will it force server operators to encrypt either/or ? If

Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacCárthaigh wrote: > > Maybe a lot of this dilemma could be avoided if the the PSKs that can be > used for regular resumption and for 0-RTT encryption were separate, with > the latter being scoped smaller and with use-at-most-once semantics. The pro