Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

There is general consensus to adopt this draft as a working group item. There is an open issue as to what content from the FFDH draft to merge into this one. While that does not prevent us from bringing the draft into the working group we will give some time to see if we can come to consensus on

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

I support adoption. David On Mon, Aug 9, 2021 at 11:24 AM Loganaden Velvindron wrote: > I also support adoption. > > On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle > wrote: > > > > I support adoption. > > > > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > > > This is a working group c

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

I also support adoption. On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle wrote: > > I support adoption. > > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

I support adoption. > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 >

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Thu, Jul 29, 2021 at 02:50:20PM -0700, Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > ). > There was

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one? Either way, I would support deprecating FFDHE completely. > On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni wrote: > > On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni writes: >with confirmation from Peter Gutmann below that any custom groups we're >likely to encounter are almost certainly safe Well, I haven't examined every crypto library on the planet, it's not to say there isn't something somewhere that implements its keygen as: for i = 0 t

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote: > Looks like we have consensus for the following: IIRC we're not looking for consensus on the substance of the draft at this point, this just a WG adoption call. So the issues below do not need to be resolved at this time... We just

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni writes: >OK, who goes around bothering to actually generate custom DH parameters, and >with what tools, but then does not use a "strong" (Sophie Germain) prime? That's better :-). That was my thought too, every DH/DLP keygen I've seen generates either Sophie Germain or FIPS 186

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

nt in the meanwhile. I'll also ask around if we can get some metrics, in general and specifically pertaining to that last point. thanks again everyone, Nimrod -- Forwarded message - From: Viktor Dukhovni Date: Sat, 31 Jul 2021 at 19:12 Subject: Re: [TLS] Adoption call for D

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >I strongly doubt there's a non-negligible server population with weak locally > >generated groups. > > Would you care to rephrase that so we can make sure you're saying what we > think you're saying in

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni writes: >I strongly doubt there's a non-negligible server population with weak locally >generated groups. Would you care to rephrase that so we can make sure you're saying what we think you're saying in order to disagree with it? Peter :-). _

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Scott Fluhrer (sfluhrer) writes: >The problem is that it is hard for the client to distinguish between a well >designed server vs a server that isn't as well written, and selects the DH >group in a naïve way. What should the client do if it could detect this? And how would it distinguish betwee

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni writes: >Can you explain what you mean by "don't do things that you should never have >been doing in the first place"? Just what the draft says, don't use static-ephemeral DH, don't reuse DHE secrets, etc. It seems a bit like publishing an RFC telling people not to stick forks i

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote: > > Was it wrong to generate server-side DH parameters? > > The problem is that it is hard for the client to distinguish between a > well designed server vs a server that isn't as well written, and > selects the DH group in

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

ktor Dukhovni Sent: Friday, July 30, 2021 2:57 PM To: tls@ietf.org Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE > &

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code > >points that use negotiated groups from the group list. But it is far from > >clear that this is worth doing given that we now have ECDHE, X25519 and X44

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni writes: >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code >points that use negotiated groups from the group list. But it is far from >clear that this is worth doing given that we now have ECDHE, X25519 and X448. There's still an awful lot of SCADA gear

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote: > On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > >

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > ). > There was suppor

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

>This is a working group call for adoption of Deprecating Obsolete Key Exchange >Methods in TLS >(draft-aviram-tls-deprecate-obsolete-kex-00