Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

On Tue, Jul 30, 2019 at 11:59 PM Martin Thomson wrote: > On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote: > > The batch signing idea is very cool. I'm not entirely sure I understand > > the intended use case, though. The intro suggests that this motivated > > by DoS defense, but presumably an

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote: > The batch signing idea is very cool. I'm not entirely sure I understand > the intended use case, though. The intro suggests that this motivated > by DoS defense, but presumably an attacker who controls their own TLS > client stack could

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

On Wed, Jul 31, 2019, at 06:21, Benjamin Kaduk wrote: > It's clear that anything we do needs to preserve compat with all four > possibilities in the interop matrix for (old, enhanced) (client, > server). Your closing note about duplicating payloads is something of a > different creature, though,

Re: [TLS] Adoption call for draft-lvelvindron-tls-md5-sha1-deprecate

I'm in favor of adoption. On Wed, Jul 24, 2019 at 11:28 AM Chris Inacio wrote: > Favor of adoption. > > > > On July 24, 2019 at 8:49:22 AM, Christopher Wood (c...@heapingbits.net) > wrote: > > At TLS@IETF105, there was interest in the room to adopt > draft-lvelvindron-tls-md5-sha1-deprecate as

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

On Tue, Jul 30, 2019 at 07:44:13PM +, Scott Fluhrer (sfluhrer) wrote: > I believe that one important property (of either of the options I listed) is > a nice fallback if an enhanced client talks to an older server. In both > cases, the server will see a series of named groups that it

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

> -Original Message- > From: Stephen Farrell > Sent: Tuesday, July 30, 2019 3:53 PM > To: Scott Fluhrer (sfluhrer) ; Watson Ladd > > Cc: TLS List > Subject: Re: [TLS] Options for negotiating hybrid key exchanges for > postquantum > > > I'm neutral as to how we represent this stuff for

[TLS] SIKE vs SIDH (was Options for negotiating hybrid key exchanges for postquantum)

This is a side issue (we’re probably not going to talk about which postquantum primitives to use for another two years), but: * What do you see as the advantage of SIDH? The server can’t arbitrarily select the shared secret (at least, if we select the KEM version of SIKE); what specific

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I'm neutral as to how we represent this stuff for the moment as I think it's too early to tell until we get closer to the end of the algorithms competition. That said, I do want to second this... On 30/07/2019 19:41, Scott Fluhrer (sfluhrer) wrote: > Here is one opinion (mine, but I'm pretty

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

> It is not clear if the proposal you outlined share this property; do you > duplicate a payload that an unenhanced server would assume only occurs once? I think this property is preserved: only a server that knows the hybrid-key-exchange extension (or perhaps, a more specific

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I believe that one important property (of either of the options I listed) is a nice fallback if an enhanced client talks to an older server. In both cases, the server will see a series of named groups that it doesn’t know (which it will ignore), and possibility an extension it doesn’t know

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

Sure, hybrid-key-exchange “flag” extension is too generic. We could have the client advertise something like one-traditional-and-one-PQ, and still avoid the Cartesian product. From: TLS On Behalf Of Blumenthal, Uri - 0553 - MITLL Sent: Tuesday, July 30, 2019 12:12 PM To: David Benjamin Cc: TLS

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

One more thing: I would expect to use SIDH rather than SIKE. Because to emulate the security advantages of DH, you’d have to run two SIKE’s – one in each direction. From: TLS on behalf of "Panos Kampanakis (pkampana)" Date: Tuesday, July 30, 2019 at 3:37 PM To: "Scott Fluhrer

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

+1 for option 2. The combinatoric explosion and complexity of 1 is unnecessary. I expect that just a few, conservative, acceptably efficient, classical+PQ combinations need to be standardized and used. Combining a classical algo with more than one postquantum algorithms in a key exchange does

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

The nuisance with just a flag is the client can't express [what I think are] reasonable preferences. It should be able to say things like: Offhand, I don’t see at all why the client should be able to say any of these “don’t”s: * Don't do X25519 + P-256. This is just silly. * Don't do

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

Oops. draft-davidben-tls-batch-signing-00 cites draft-davidben-http2-tls13-00. That should be draft-davidben-tls13-pkcs1-00. (The XML file took a really long time to be created, so I manually tried to recreate it based on another file and forgot to update one of the fields.) I'll fix this in -01.

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

The nuisance with just a flag is the client can't express [what I think are] reasonable preferences. It should be able to say things like: * Don't do X25519 + P-256. This is just silly. * Don't do PQ1 on its own. I really want the PQ scheme paired with something more established. * Don't do PQ1 +

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

From: Watson Ladd > On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer) > wrote: >> During the physical meeting in Montreal, we had a discussion about >> postquantum security, and in particular, on how one might want to negotiate >> several different ‘groups’

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I think this underestimates the complexity cost of option 1 to the protocol and implementations. Option 1 means group negotiation includes entire codepoints whose meaning cannot be determined without a parallel extension. This compounds across everything which interacts with named groups,

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer) wrote: > During the physical meeting in Montreal, we had a discussion about > postquantum security, and in particular, on how one might want to negotiate > several different ‘groups’ simultaneously (because there might not be one > group

[TLS] Options for negotiating hybrid key exchanges for postquantum

During the physical meeting in Montreal, we had a discussion about postquantum security, and in particular, on how one might want to negotiate several different 'groups' simultaneously (because there might not be one group that is entirely trusted, and I put 'groups' in scarequotes because