Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Ack, of course. My views are the same tho. From: Joseph Salowey Date: Monday, August 30, 2021 at 2:32 PM To: Rich Salz Cc: "tls@ietf.org" Subject: Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS On Mon, Aug 30, 2021 at 10:47 AM Salz, Rich mailto:rs...@

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Mon, Aug 30, 2021 at 10:47 AM Salz, Rich wrote: > By “obsolete keyex draft” you mean expired, right? > > > [Joe] I mean this draft - draft-aviram-tls-deprecate-obsolete-kex-00 (the subject of the other adoption call). There were several comments that we should merge the two drafts. Since

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

By “obsolete keyex draft” you mean expired, right? I am in favor of MUST NOT have a certificate with DH keys. So yes to 1. I think #2 is unenforceable/undetectable, but would be happy to be convinced otherwise. So I’m unsure about #2. But yes, let’s adopt and merge in the expired keyex draft

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Sorry, I'm not sure what you mean? > On Aug 28, 2021, at 6:20 PM, Rob Sayre wrote: > > On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle > wrote: > All the ciphersuites mentioned in the draft under discussion are already > listed as not recommended because they

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle wrote: > All the ciphersuites mentioned in the draft under discussion are already > listed as not recommended because they don't offer forward secrecy. > Excellent. How much WG time should we waste on so-called "embedded" use cases? thanks, Rob

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

In the revision of this draft (https://tools.ietf.org/pdf/draft-bartle-tls-deprecate-ffdh-00.pdf), which was unfortunately not the revision sent out on this call for adoption, we cite invalid curve attacks as a reason to advise against ECDH:

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

All the ciphersuites mentioned in the draft under discussion are already listed as not recommended because they don't offer forward secrecy. > On Aug 27, 2021, at 11:01 AM, Rob Sayre wrote: > > On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda > wrote: > > If a

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

ik < >> rstruik@gmail.com> >> *Date: *Friday, August 13, 2021 at 09:58 >> Dear colleagues: >> >> I think this document should absolutely *not* be adopted, without >> providing far more technical justification. The quoted Raccoon attack is an >&g

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda wrote: > > If a consistent history of directly linked vulnerabilities across major > implementations doesn't show something is unsafe, I don't think there is > progress to be made in the discussion. Blaming the implementers is not > particularly

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

ch secure implementations are known. No detail is provided and that alone should be sufficient reason to not adopt. Rene On 2021-07-29 5:50 p.m., Joseph Salowey wrote: This is a working group call for adoption for Deprecating FFDH(E

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

A closer look at your referenced CVEs suggests these can be classified as (i) lack of checking for improperly generated DH groups; (ii) exploiting overflow/underflow/carry bugs. To me, nothing seems to be new here and more likely a failure of implementers to heed to results and advice predating

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

te attack (which has nothing to do with finite field groups, > just with poor design choices of postprocessing, where one uses > variable-size integer representations for a key). There are also good > reasons to have key exchanges where one of the parties has a static key, > whether ecc-based

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

2021-08-27 17:25 GMT+02:00 Rene Struik : > {officially on vacation till Labor Day, but weighing-in briefly} > > Hi Filippo: > > I had a brief look at the CVEs you referenced and at your Blackhat 2018 > presentation. > > Some observations on your Blackhat 2018 presentaton: (a) the attack seems

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

{officially on vacation till Labor Day, but weighing-in briefly} Hi Filippo: I had a brief look at the CVEs you referenced and at your Blackhat 2018 presentation. Some observations on your Blackhat 2018 presentaton: (a) the attack seems to be a reincarnation of the so-called Goubin attack

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

wey wrote: This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this draft at the IETF 110 meeting and since it is a similar topic to the key exchange deprecation draft the chairs want to get a se

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

>>>>> >>>>> *Date: *Friday, August 13, 2021 at 09:58 >>>>> >>>>> Dear colleagues: >>>>> >>>>> I think this document should absolutely *not* be adopted, without >>>>> providing far more te

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

e of the parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), for which secure implementations are known. No detail is provided and that alone should be sufficient reason to not adopt. Rene On 2021-07-29 5:50 p.m., Joseph Salowey wrote: This is a working gro

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

_ >>>> I think this document should absolutely *not* be adopted, without >>>> providing far more technical justification. The quoted Raccoon attack is >>>> an easy to mitigate attack (which has nothing to do with finite field >>>> groups, just with poor desi

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

atic key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations are known. No detail is provided and that alone should be > sufficient reason to not adopt. > > Rene > > On 2021-07-29 5:50 p.m., Joseph Salowey wrote: > > This is a worki

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

rties has a static key, whether ecc-based or >> ff-based (e.g., sni, opaque), for which secure implementations are known. No >> detail is provided and that alone should be sufficient reason to not adopt. >> >> Rene >> >> On 2021-07-29 5:50 p.m., Joseph Salo

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On 8/17/21, 16:16, "Benjamin Kaduk" wrote: >On Tue, Aug 17, 2021 at 07:25:33PM +, Blumenthal, Uri - 0553 - MITLL > wrote: >> I see absolutely nothing wrong with using FFDH(E) and ECDH, >> as long as at least one of the keys is ephemeral. >> There is no need to “warn away”,

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

David Benjamin writes: >RFC7919 tried to solve the problem but, by reusing the old cipher suites, it >fails to solve the problem. It didn't just not solve the problem, it made things worse: 7919 doesn't say "I want to do DHE, if possible with these parameters", it says "I will only accept DHE

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Deprecating non-forward-secure ECDH and FFDH is important. Keeping FFDHE may be okay, e.g. for those who want forward security, but still don't trust ECC. -- This transmission (including any attachments) may contain

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Tue, Aug 17, 2021 at 07:25:33PM +, Blumenthal, Uri - 0553 - MITLL wrote: > I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at > least one of the keys is ephemeral. There is no need to “warn away”, IMHO. That's an interesting position to take. Let me see if I

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

I also support. On Tue, Aug 17, 2021 at 11:19 PM Salz, Rich wrote: > > I still support adoption, as I said a couple of weeks ago. I also still think > we should consider merging this and > draft-aviram-tls-deprecate-obsolete-kex-00. > > > > I know that I’ve also said this before (can’t find it

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at least one of the keys is ephemeral. There is no need to “warn away”, IMHO. Regards, Uri > On Aug 17, 2021, at 15:19, Salz, Rich > wrote: > >  > I still support adoption, as I said a couple of weeks ago. I also still

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

I still support adoption, as I said a couple of weeks ago. I also still think we should consider merging this and draft-aviram-tls-deprecate-obsolete-kex-00. I know that I’ve also said this before (can’t find it in my “sent mail” folder), but the fact that some communities can still use this

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

h poor design choices of postprocessing, where one uses > variable-size integer representations for a key). There are also good > reasons to have key exchanges where one of the parties has a static key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

aque), for which secure implementations are known. No detail is provided and that alone should be sufficient reason to not adopt. Rene On 2021-07-29 5:50 p.m., Joseph Salowey wrote: This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-dep

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

-size integer representations for a key). There are also good > reasons to have key exchanges where one of the parties has a static key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations are known. No detail is provided and that alone should be > suf

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

ecure implementations are known. No >> detail is provided and that alone should be sufficient reason to not >> adopt. >> __ __ >> Rene >> __ __ >> On 2021-07-29 5:50 p.m., Joseph Salowey wrote: >>> This is a working group call for adoption for Depreca

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

tic key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations are known. No detail is provided and that alone should be > sufficient reason to not adopt. > > > > Rene > > > > On 2021-07-29 5:50 p.m., Joseph Salowey wrote: > >

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

-based or ff-based (e.g., sni, opaque), for which secure implementations are known. No detail is provided and that alone should be sufficient reason to not adopt. Rene On 2021-07-29 5:50 p.m., Joseph Salowey wrote: This is a working group call for adoption for Deprecating FFDH(E

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

be sufficient reason to not adopt. Rene On 2021-07-29 5:50 p.m., Joseph Salowey wrote: This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). We had a presen

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

is right; I >> could tolerate a prohibition on reuse for ECDH, but I know that we rely on >> that for HPKE and other things, so it can't really be bad enough to ban. >> >> Cheers, >> Martin >> >> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: >>> T

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

> On 6 Aug 2021, at 3:31 pm, Benjamin Kaduk > wrote: > >> That said, I've given up fighting potentially counter-productive "raising >> the floor" >> rather than "the celing" on all fronts, and now try to focus on just the >> most important >> cases. Thus have accepted the fact that sadly no

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Fri, Aug 06, 2021 at 03:03:47PM -0400, Viktor Dukhovni wrote: > > That said, I've given up fighting potentially counter-productive "raising the > floor" > rather than "the celing" on all fronts, and now try to focus on just the most > important > cases. Thus have accepted the fact that

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

> On 6 Aug 2021, at 2:51 pm, Ilari Liusvaara wrote: > > As note: the DH_anon and ECDH_anon names are a bit misleading: Those > two are actually ephemeral (but are still rarely a good idea to use) For what it is worth, anon DH, and anon ECDH ciphers are used by default in Postfix when doing

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Sat, Jul 31, 2021, at 06:25, Carrick Bartle wrote: > are you opposed to fully deprecating FFDHE? If so, why? No so much opposed as that it is not necessary. Though the TLS 1.2 variant is - as others have noted - close to impossible to negotiate the "good" groups, it's not concretely bad

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: >> This is a working group call for adoption for Deprecating FFDH(E) >> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 >> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/ >> <

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

reuse for ECDH, but I know that we rely on > that for HPKE and other things, so it can't really be bad enough to ban. > > Cheers, > Martin > > On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: >> This is a working group call for adoption for Deprecating FFDH(E) >&

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

ion for Deprecating FFDH(E) > Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 > <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). > We had a presentation for this draft at the IETF 110 meeting and since > it is a similar topic to the key exchange depreca

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

* This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/__;!!GjvTz_vk!FlMZCO0a7tFKUtFIzYQuaGPHZKDkHN8YLu7ao9lNmCL1UYhg9sfLscTcr

[TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). We had a presentation for this draft at the IETF 110 meeting and since it is a similar topic to t