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

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Aug 2021 21:51:07 +0300

On Thu, Jul 29, 2021 at 02:50:24PM -0700, 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 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 sense if the working group wants to adopt this draft (perhaps the
> drafts could be merged if both move forward).  Please review the draft and
> post your comments to the list by Friday, August 13, 2021.

I do not support adoption, as I think this stuff should be folded into
deprecate-obsolete-kex.

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).

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 15:03:47 -0400

> On 6 Aug 2021, at 2:51 pm, Ilari Liusvaara <[email-masked]> wrote:
> 
> 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 unauthenticated opportunistic TLS.  Since the server
certificate is ignored, we don't bother to solicit one, or offer one if the
client does not care.

See also:

  https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

where I explained that I see security advantages to making transparent the
client's non-use of a server certificate.

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 anon (EC)DH ciphers are available with
TLS 1.3.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Aug 2021 12:31:36 -0700

> cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are available with

Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 15:39:33 -0400

> On 6 Aug 2021, at 3:31 pm, Benjamin Kaduk <bkaduk=[email-masked]> wrote:
> 

Yes, correct on a technicality: for anon_DH I'd need a null signature scheme,
but the intended point was that TLS without server certificates is presently
not supported in TLS 1.3.  I have not chose to campain to bring it back at
this time...

-- 
	Viktor.

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 9 Aug 2021 11:14:45 -0700

I've posted a revision here: https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/ <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/>

> On Jul 30, 2021, at 11:56 AM, Carrick Bartle <cbartle891=[email-masked]> wrote:
> 
> Sorry, the title will be changed in the next version, which I'll be posting as soon as possible. You are correct about the scope of the work.
> 
> 
>> On Jul 29, 2021, at 5:41 PM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> I support the *contents* of this document.  The title, however, I can't agree to.  So I want to be clear about the scope of the work, namely deprecating semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with reused keys.
>> 
>> The draft limits the ban on ephemeral key reuse to FFDHE, which 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:
>>> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/ <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 deprecation draft the chairs 
>>> want to get a sense if the working group wants to adopt this draft 
>>> (perhaps the drafts could be merged if both move forward).  Please 
>>> review the draft and post your comments to the list by Friday, August 
>>> 13, 2021.  
>>> 
>>> Thanks,
>>> 
>>> The TLS chairs
>>> _______________________________________________
>>> TLS mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Rene Struik <[email-masked]>
Date: Fri, 13 Aug 2021 09:56:51 -0400

Dear colleagues:

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 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 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:
> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). 

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 13 Aug 2021 17:20:18 +0000

I agree with Rene’s points.

-- 

Regards,

Uri

From: TLS <[email-masked]> on behalf of Rene Struik <[email-masked]>
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 easy to mitigate 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 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

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 sense if the working group wants to adopt this draft (perhaps the drafts could be merged if both move forward).  Please review the draft and post your comments to the list by Friday, August 13, 2021.  

Thanks,

The TLS chairs

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 16 Aug 2021 18:45:31 -0700

Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do
not provide forward secrecy, which is a main reason cited for deprecating
RSA in draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the
citation of the Raccoon attack or do you also feel that we should keep
these ciphersuites that do not provide forward secrecy around?

Cheers,

Joe

On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> *From: *TLS <[email-masked]> on behalf of Rene Struik <
> [email-masked]>
> *Date: *Friday, August 13, 2021 at 09:58
>
> Dear colleagues:
>
>
>
> 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 design choices of postprocessing, where one uses
> implementations are known. No detail is provided and that alone should be
> sufficient reason to not adopt.
>
>
>
> Rene
>
>
>

---

From: "Filippo Valsorda" <[email-masked]>
Date: Tue, 17 Aug 2021 15:28:22 +0200

(I am listed as author to one of the drafts, but haven't contributed significantly since suggesting the deprecation on the list, so I am going to renounce authorship and express my support for the adoption instead.)

As a TLS implementer, I don't want the specs to tell me what is *technically possible to implement correctly*. I want the specs to recommend the safer, most straightforward options for general purpose use.

*DH reuse is less safe than ephemeral shares.* I don't think we need to debate this fact. There is a mile-high pile of CVEs that include the words "if DH shares are reused". I personally turned a 2^-32 chance of a carry bug into a full key recovery against ES-DH <https://www.youtube.com/watch?v=zPj5tTFDql0>, others have pulled off more and cooler attacks. None of these fun, job-security-providing stunts work with ephemeral shares, so it's with a heavy heart that I say we should absolutely deprecate all DH share reuses. (This includes all static kex, and an explicit MUST NOT for reuse in ephemeral kex.)

*Checking the safety of an arbitrary FFDH group is relatively hard, and slow.* Implementers tend to skip hard, slow operations with no visible outcome. Besides, it's also a compatibility risk, because the only recourse on a failed check is to terminate the connection, which again encourages implementers to skip or relax the check. The most straightforward path to retaining FFDH in TLS 1.2 I see is requiring the use of a few, well known groups, that can be checked by memcmp. Still, I would rather support deprecating pre-TLS 1.3 FFDH entirely.

It's not like things in the wild suddenly stop working when the IETF deprecates a cipher suite (that's my job!), it just tells bystanders "this is not the best way to do things" and in the case of DH reuse "you'll be much safer if you generate fresh shares" and in the case of FFDH "if you want to do FFDH it will be safer and more reliable to use TLS 1.3".

I support adoption, and recommend merging all these deprecations into a single draft, which would be easier to refer to and communicate as an implementer.

2021-08-17 03:45 GMT+02:00 Joseph Salowey <[email-masked]>:
> Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not provide forward secrecy, which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the citation of the Raccoon attack or do you also feel that we should keep these ciphersuites that do not provide forward secrecy around?
> 
> Cheers,
> 
> Joe
> 
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>> I agree with Rene’s points.____
>> __ __
>> -- ____
>> Regards,____
>> Uri____
>> __ __
>> __ __
>> *From: *TLS <[email-masked]> on behalf of Rene Struik <[email-masked]>
>> ____
>> Dear colleagues:____
>> __ __
>> 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 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 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-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 deprecation draft the chairs want to get a sense if the working group wants to adopt this draft (perhaps the drafts could be merged if both move forward).  Please review the draft and post your comments to the list by Friday, August 13, 2021.  ____
>>> __ __
>>> Thanks,____
>>> __ __
>>> The TLS chairs____
>>> 
>>> ____
>>> 
>>> ___________________________________________________
>>> TLS mailing list____
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tls____
>> __ __
>> 
>> -- ____
>> email: [email-masked] | Skype: rstruik____
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867____

---

From: David Benjamin <[email-masked]>
Date: Tue, 17 Aug 2021 11:51:56 -0400

I support adoption, and will second everything Filippo says.

Deprecation is about the working group issuing updated guidance. Existing
ecosystems may apply new guidance at different rates. That's up to TLS
implementations and deployments to work through. Some ecosystems may remove
things at long time scales. Some ecosystems may have particularly unusual
setups such that they almost never want to remove anything. That's fine,
but it cannot discount the other ecosystems which *do *incur security risk
from having weak ciphers enabled, or the new TLS uses with no legacy. The
working group needs to maintain up-to-date guidance here, and this is how
we do that.

On arbitrary FFDH groups, I think pre-TLS-1.3 FFDH, even ephemeral, is
unsalvageable [again, as up-to-date guidance, see above]. We don't have a
way to tell the server to only consider DHE ciphers if it would have used a
group the client supports. RFC7919 tried to solve the problem but, by
reusing the old cipher suites, it fails to solve the problem. Triggering an
external client retry instead has interesting downgrade consequences due to
ServerKeyExchange signatures not covering the ClientHello. (In fact, I
suspect RFC7919 has made the downgrade risks worse...)

On Tue, Aug 17, 2021 at 9:29 AM Filippo Valsorda <[email-masked]>
wrote:

> (I am listed as author to one of the drafts, but haven't contributed
> significantly since suggesting the deprecation on the list, so I am going
> to renounce authorship and express my support for the adoption instead.)
>
> As a TLS implementer, I don't want the specs to tell me what is *technically
> possible to implement correctly*. I want the specs to recommend the
> safer, most straightforward options for general purpose use.
>
> *DH reuse is less safe than ephemeral shares.* I don't think we need to
> debate this fact. There is a mile-high pile of CVEs that include the words
> "if DH shares are reused". I personally turned a 2^-32 chance of a carry
> bug into a full key recovery against ES-DH
> <https://www.youtube.com/watch?v=zPj5tTFDql0>, others have pulled off
> more and cooler attacks. None of these fun, job-security-providing stunts
> work with ephemeral shares, so it's with a heavy heart that I say we should
> absolutely deprecate all DH share reuses. (This includes all static kex,
> and an explicit MUST NOT for reuse in ephemeral kex.)
>
> *Checking the safety of an arbitrary FFDH group is relatively hard, and
> slow.* Implementers tend to skip hard, slow operations with no visible
> outcome. Besides, it's also a compatibility risk, because the only recourse
> on a failed check is to terminate the connection, which again encourages
> implementers to skip or relax the check. The most straightforward path to
> retaining FFDH in TLS 1.2 I see is requiring the use of a few, well known
> groups, that can be checked by memcmp. Still, I would rather support
> deprecating pre-TLS 1.3 FFDH entirely.
>
> It's not like things in the wild suddenly stop working when the IETF
> deprecates a cipher suite (that's my job!), it just tells bystanders "this
> is not the best way to do things" and in the case of DH reuse "you'll be
> much safer if you generate fresh shares" and in the case of FFDH "if you
> want to do FFDH it will be safer and more reliable to use TLS 1.3".
>
> I support adoption, and recommend merging all these deprecations into a
> single draft, which would be easier to refer to and communicate as an
> implementer.
>
> cell: +1 (647) 867-5658 <(647)%20867-5658> | US: +1 (415) 287-3867 <(415)%20287-3867>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 17 Aug 2021 17:41:02 +0000

>  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not provide

>  forward secrecy,

Unless you use semi-static exchange, which in many cases makes sense.

>   which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.

Have the authors look at Post-Quantum KEMs?

>  Do you object to just the citation of the Raccoon attack or do you also feel that we

>  should keep these ciphersuites that do not provide forward secrecy around?

I think these suites should stay around. 

While static-static indeed do not provide forward secrecy (and many of us – though not everybody! – carry for that), static-ephemeral DH and ECDH are perfectly fine from that point of view.

-- 

Regards,

Uri

Dear colleagues:

Rene

Thanks,

The TLS chairs

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Aug 2021 10:56:33 -0700

>
>
> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
>
>

FWIW I don't think we should use post-quantum KEMs in pure "static" modes
(a la traditional static RSA).

-Ekr

> While static-static indeed do not provide forward secrecy (and many of us
> – though not everybody! – carry for that), static-ephemeral DH and ECDH are
> perfectly fine from that point of view.
>
>
>
>
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Aug 2021 19:18:15 +0000

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 safely, or must use it (for a variety of reasons usually around the infeasibility of upgrading), doesn’t mean that the general populace should not be warned away from doing these kinds of things.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 17 Aug 2021 19:25:33 +0000

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 <rsalz=[email-masked]> wrote:
> 
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 17 Aug 2021 23:33:03 +0400

I also support.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Aug 2021 13:15:44 -0700

> 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 understand it correctly.
(I will just write "DH" even though I mean (EC)DH.)

Static-static DH results in re-generating the same derived key on multiple protocol
instantiations, which is in some sense reusing a single key for multiple things and
thus disrecommended.  Though, in TLS, we have the Randoms that go into the key schedule,
so the actual traffic/Finished/etc. keys will diverge even for the static-static case.
However, it's hard to do formal analysis when the same secret is used across many
protocol instantiations spread out over time, and one has to ensure that the Randoms
actually are non-repeating in order for this to be a reliable scheme.  So there's plenty
of risk here and reasons to stay away.

Ephemeral-static DH makes a new derived key for each protocol instantiation and
simplifies the analysis (though subject to similar caveats as above about actually
using a unique ephemeral value each time).  It's clearly an improvement over static-static,
but anyone armed with a protocol transcript who discovers the secret part of the static
DH value can recover the derived key and deprotect the application data.  Forward secrecy
is not obtained until the "static" private value is discarded, leaving risk of loss
of confidentiality due to endpoint compromise.

Ephemeral-ephemeral DH also makes a new derived key for each protocol instantiation, but
also allows the private DH values to be discarded "immediately", before any significant
application data is protected using key material stemming from the derived key.  This provides
the strongest kind of forward secrecy (provided that endpoints actually discard the private
ephemeral values), and is again a step up from the ephemeral-static case.

In light of the above, it seems that your concerns are more focused on "key reuse" than
forward secrecy.  Is that correct?
I have heard a lot of people saying that forward secrecy is important to them, so it's
not clear that your stance is the consensus position.

Thanks,

Ben

---

From: Dan Brown <[email-masked]>
Date: Tue, 17 Aug 2021 20:56:41 +0000

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 confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Aug 2021 12:32:19 +0000

David Benjamin <[email-masked]> 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 if you use these parameters, otherwise you cannot use DHE but must
drop back to RSA".  Because of this and other issues, a discussion on this
list in 2019 indicated that no-one was planning to implement it.

>We don't have a way to tell the server to only consider DHE ciphers if it
>would have used a group the client supports.

Why would that be an issue?  I know 7919 invents a bunch of reasons why this
could be a problem, but in practice you just connect and take what the server
gives you.  If you don't like it you can always choose not to connect, but
it's not like someone is going to rekey or rebuild the server if the client
says it doesn't like the DH group it's offering.

Given that everyone seems to have a different idea of what is and isn't a
problem and what does and doesn't need to be addressed, perhaps we first need
to define what we're trying to achieve...

Peter.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 18 Aug 2021 13:23:58 +0000

On 8/17/21, 16:16, "Benjamin Kaduk" <[email-masked]> 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. 

>    (I will just write "DH" even though I mean (EC)DH.)

And a very nice analysis, thank you!

>    thus disrecommended. .  .  .  . So there's plenty of risk here and reasons to stay away.

Correct. Agreed.

>    simplifies the analysis  .  .  .  but anyone armed with a protocol transcript
>    who discovers the secret part of the static DH value can recover the derived
>    key and deprotect the application data.  Forward secrecy is not obtained until
>    the "static" private value is discarded, leaving risk of loss

Correct. Relative risks and concerns of client vs. server security are out of scope for
this discussion.

>    Ephemeral-ephemeral DH also makes a new derived key for each protocol instantiation,
>    but also allows the private DH values to be discarded "immediately",  .  .  .  .  .

I'd say, "*requires* the private DH values to be discarded 'immediately'".

>    This provides the strongest kind of forward secrecy (provided that endpoints
>    actually discard the private ephemeral values), and is again a step up from
>    the ephemeral-static case.

It certainly is, and IMHO it's the preferred way, unless realities (of the environment, etc.) disallow it.

>    forward secrecy.  Is that correct?

Ha! Both are important, but absolutely - "key reuse" is a much bigger (and immediate!) concern.
In my environment there are other ways to mitigate (not alleviate completely!) the threat to
forward secrecy.

>    not clear that your stance is the consensus position.

I cannot claim consensus. Forward secrecy is probably as important to me as it is to the next guy - it's about the price I'd have to pay for it, the relative (not necessarily monetary) cost, and the willingness to consider other mitigation methods.

Thanks!

---

From: Carrick Bartle <[email-masked]>
Date: Sun, 22 Aug 2021 21:32:51 -0700

> Have the authors look at Post-Quantum KEMs?

I'm not sure why PQ KEMs are relevant here.

> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <[email-masked] <mailto:[email-masked]>> wrote:
>> From: TLS <[email-masked] <mailto:[email-masked]>> on behalf of Rene Struik <[email-masked] <mailto:[email-masked]>>
>>> 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 the key exchange deprecation draft the chairs want to get a sense if the working group wants to adopt this draft (perhaps the drafts could be merged if both move forward).  Please review the draft and post your comments to the list by Friday, August 13, 2021.  
>>>  
>>> Thanks,
>>>  
>>> The TLS chairs
>>>  
>>> 
>> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 26 Aug 2021 20:08:39 -0700

Thanks for all the discussion on this topic.  There are several modes that
TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to
merge some of the cases covered by this draft into the obsolete keyex
draft.  I'd like to see if there is some consensus to make this change
before we adopt it into the working group.

1. static-static where both client and server have DH certificates with
long term keys.  I think we have general consensus that this mode should be
a must not.  To deprecate this mode I think we need to state that clients
MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and server
MUST NOT request them.  Would the working group support merging this
guidance into the obsolete keyex draft?

2. ephemeral-static where the client uses an ephemeral key and the server
uses a long term key.  This mode does not provide forward secrecy.  I'm not
sure we have reached consensus on how far to deprecate this option.  Would
the working group support MUST NOT use these ciphersuites unless forward
secrecy does not matter for your use case and any implementation guidance
provided to avoid weaknesses is followed?

3. ephemeral-ephemeral  - I think these are already covered in the obsolete
keyex draft.

Thanks,

Joe

---

From: "Filippo Valsorda" <[email-masked]>
Date: Fri, 27 Aug 2021 11:24:25 +0200

2021-08-27 05:08 GMT+02:00 Joseph Salowey <[email-masked]>:
> Thanks for all the discussion on this topic.  There are several modes that TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to merge some of the cases covered by this draft into the obsolete keyex draft.  I'd like to see if there is some consensus to make this change before we adopt it into the working group. 
> 
> 1. static-static where both client and server have DH certificates with long term keys.  I think we have general consensus that this mode should be a must not.  To deprecate this mode I think we need to state that clients MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT request them.  Would the working group support merging this guidance into the obsolete keyex draft?  
> 
> 2. ephemeral-static where the client uses an ephemeral key and the server uses a long term key.  This mode does not provide forward secrecy.  I'm not sure we have reached consensus on how far to deprecate this option.  Would the working group support MUST NOT use these ciphersuites unless forward secrecy does not matter for your use case and any implementation guidance provided to avoid weaknesses is followed?

The implementation guidance to avoid weaknesses in any ephemeral-static exchange is "don't get anything wrong, anything at all, all the way down to your field arithmetic libraries". I don't think that's a workable recommendation, and I believe we should deprecate modes that are so unsafe to implement.

> 3. ephemeral-ephemeral  - I think these are already covered in the obsolete keyex draft. 
> 
> Thanks,
> 
> Joe
> 
> On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle <[email-masked]> wrote:
>>> >   which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.____
>>>  
>>> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not provide____
>>> >  forward secrecy,____
>>> __ __
>>> Unless you use semi-static exchange, which in many cases makes sense.____
>>> __ __
>>> >   which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.____
>>> __ __
>>> Have the authors look at Post-Quantum KEMs?____
>>> __ __
>>> >  Do you object to just the citation of the Raccoon attack or do you also feel that we____
>>> >  should keep these ciphersuites that do not provide forward secrecy around?____
>>> __ __
>>> I think these suites should stay around. ____
>>> __ __
>>> While static-static indeed do not provide forward secrecy (and many of us – though not everybody! – carry for that), static-ephemeral DH and ECDH are perfectly fine from that point of view.____
>>> __ __
>>> __ __
>>> __ __
>>> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:____
>>>> *Date: *Friday, August 13, 2021 at 09:58____
>>>> Dear colleagues:____
>>>>  ____

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 27 Aug 2021 13:13:41 +0000

static-static where both client and server have DH certificates with long term keys.  I think we have general consensus that this mode should be a must not.  To deprecate this mode I think we need to state that clients MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT request them.  Would the working group support merging this guidance into the obsolete keyex draft?  

Static-static is OK only when coupled with ephemeral (for forward secrecy), using the static part for implicit mutual authentication. Not good when used “alone”. Within the TLS context, OK to “MUST NOT”.

ephemeral-static where the client uses an ephemeral key and the server uses a long term key.  This mode does not provide forward secrecy.  I'm not sure we have reached consensus on how far to deprecate this option.  Would the working group support MUST NOT use these ciphersuites unless forward secrecy does not matter for your use case and any implementation guidance provided to avoid weaknesses is followed?
Forward secrecy here is “asymmetric”: “server fails” -> “secrecy fails”. There are use cases…

I recommend “SHOULD NOT” here.

[FV] The implementation guidance to avoid weaknesses in any ephemeral-static exchange is "don't get anything wrong, anything at all, all the way down to your field arithmetic libraries". I don't think that's a workable recommendation, and I believe we should deprecate modes that are so unsafe to implement.

Static-ephemeral is not “so unsafe to implement”, not any more than any other mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

ephemeral-ephemeral  - I think these are already covered in the obsolete keyex draft. 
Absolutely no reason to deprecate or obsolete this mode.

 

 

-- 

Regards,

Uri

Dear colleagues:

Rene

Thanks,

The TLS chairs

TLS mailing list

[email-masked]

TLS mailing list

[email-masked]

---

From: "Filippo Valsorda" <[email-masked]>
Date: Fri, 27 Aug 2021 15:34:18 +0200

2021-08-27 15:13 GMT+02:00 Blumenthal, Uri - 0553 - MITLL <[email-masked]>:
>>  1. ephemeral-static where the client uses an ephemeral key and the server uses a long term key.  This mode does not provide forward secrecy.  I'm not sure we have reached consensus on how far to deprecate this option.  Would the working group support MUST NOT use these ciphersuites unless forward secrecy does not matter for your use case and any implementation guidance provided to avoid weaknesses is followed?
> Static-ephemeral is _not_ “so unsafe to implement”, not any more than any other mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

This is empirically disproved by a number of vulnerabilities that are exploitable (or near-misses for other reasons) only in ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a good explanation of how these attacks work, and you might find https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf interesting as well.

Anyway, we keep going in circles around what deprecation is. In my opinion, an IETF deprecation doesn't "kill off" anything, it just says it's not encouraged, so it sounds like you support deprecation in those terms.

>  
>>  1. ephemeral-ephemeral  - I think these are already covered in the obsolete keyex draft. 
> *Attachments:*
>  * smime.p7s

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 27 Aug 2021 13:54:00 +0000

Do we agree on “SHOULD NOT”?

 

 

-- 

Regards,

Uri

Dear colleagues:

Rene

Thanks,

The TLS chairs

TLS mailing list

[email-masked]

-- 

TLS mailing list

[email-masked]

TLS mailing list

[email-masked]

 

Attachments:

·         smime.p7s

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Aug 2021 11:25:58 -0400

{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 presented 19 
years earlier (in 1999); (b) the attack requires many (100s) of reuses 
of the same private key string. Both the 1999 attack and your Blackhat 
2018 version can be easily prevented if one uses blinded private keys.

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 the CVEs by years (and sometimes decades) or in QA 
processes. E.g., with respect to (i), one had not gotten oneself into 
trouble if one had actually bothered to implement domain parameter 
checks. In the literature of implementation attacks, OpenSSL has proven 
to be an excellent "implementation security flaw paper generator".

I have yet to see evidence that ephemeral-static ECDH would be 
inherently insecure.

Rene

On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:
> [snip]
>
> This is empirically disproved by a number of vulnerabilities that are 
> exploitable (or near-misses for other reasons) only in 
> ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, 
> CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the 
> past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. 
> https://eprint.iacr.org/2011/633 <https://eprint.iacr.org/2011/633> 
> gives a good explanation of how these attacks work, and you might find 
> https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf 
> <https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf> 
> interesting as well.
>
> OpenSSL:
>
> CVE-2016-0701: improper generation of Diffie-Hellman group
>
> The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 
> before 1.0.2f does not ensure that prime numbers are appropriate for 
> Diffie-Hellman (DH) key exchange, which makes it easier for remote 
> attackers to discover a private DH exponent by making multiple 
> handshakes with a peer that chose an inappropriate number, as 
> demonstrated by a number in an X9.42 file.
>
> CVE-2016-7055: carry-propagation bug
>
> There is a carry propagating bug in the Broadwell-specific Montgomery 
> multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that 
> handles input lengths divisible by, but longer than 256 bits. Analysis 
> suggests that attacks against RSA, DSA and DH private keys are 
> impossible. This is because the subroutine in question is not used in 
> operations with the private key itself and an input of the attacker's 
> direct choice. Otherwise the bug can manifest itself as transient 
> authentication and key negotiation failures or reproducible erroneous 
> outcome of public-key operations with specially crafted input. Among 
> EC algorithms only Brainpool P-512 curves are affected and one 
> presumably can attack ECDH key negotiation. Impact was not analyzed in 
> detail, because pre-requisites for attack are considered unlikely. 
> Namely multiple clients have to choose the curve in question and the 
> server has to share the private key among them, neither of which is 
> default behaviour. Even then only clients that chose the curve will be 
> affected.
>
> CVE-2017-3732: carry-propagation bug
>
> There is a carry propagating bug in the x86_64 Montgomery squaring 
> procedure in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No 
> EC algorithms are affected. Analysis suggests that attacks against RSA 
> and DSA as a result of this defect would be very difficult to perform 
> and are not believed likely. Attacks against DH are considered just 
> feasible (although very difficult) because most of the work necessary 
> to deduce information about a private key may be performed offline. 
> The amount of resources required for such an attack would be very 
> significant and likely only accessible to a limited number of 
> attackers. An attacker would additionally need online access to an 
> unpatched system using the target private key in a scenario with 
> persistent DH parameters and a private key that is shared between 
> multiple clients. For example this can occur by default in OpenSSL DHE 
> based SSL/TLS ciphersuites. Note: This issue is very similar to 
> CVE-2015-3193 but must be treated as a separate problem.
>
> CVE-2017-3736: carry-propagation bug
>
> There is a carry propagating bug in the x86_64 Montgomery squaring 
> procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC 
> algorithms are affected. Analysis suggests that attacks against RSA 
> and DSA as a result of this defect would be very difficult to perform 
> and are not believed likely. Attacks against DH are considered just 
> feasible (although very difficult) because most of the work necessary 
> to deduce information about a private key may be performed offline. 
> The amount of resources required for such an attack would be very 
> significant and likely only accessible to a limited number of 
> attackers. An attacker would additionally need online access to an 
> unpatched system using the target private key in a scenario with 
> persistent DH parameters and a private key that is shared between 
> multiple clients. This only affects processors that support the BMI1, 
> BMI2 and ADX extensions like Intel Broadwell (5th generation) and 
> later or AMD Ryzen.
>
> CVE-2017-3738: overflow bug
>
> There is an overflow bug in the AVX2 Montgomery multiplication 
> procedure used in exponentiation with 1024-bit moduli. No EC 
> algorithms are affected. Analysis suggests that attacks against RSA 
> and DSA as a result of this defect would be very difficult to perform 
> and are not believed likely. Attacks against DH1024 are considered 
> just feasible, because most of the work necessary to deduce 
> information about a private key may be performed offline. The amount 
> of resources required for such an attack would be significant. 
> However, for an attack on TLS to be meaningful, the server would have 
> to share the DH1024 private key among multiple clients, which is no 
> longer an option since CVE-2016-0701. This only affects processors 
> that support the AVX2 but not ADX extensions like Intel Haswell (4th 
> generation). Note: The impact from this issue is similar to 
> CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 
> 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. 
> Due to the low severity of this issue we are not issuing a new release 
> of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 
> 1.1.0h when it becomes available. The fix is also available in commit 
> e502cc86d in the OpenSSL git repository.
>
> CVE-2019-1551: overflow bug
>
> There is an overflow bug in the x64_64 Montgomery squaring procedure 
> used in exponentiation with 512-bit moduli. No EC algorithms are 
> affected. Analysis suggests that attacks against 2-prime RSA1024, 
> 3-prime RSA1536, and DSA1024 as a result of this defect would be very 
> difficult to perform and are not believed likely. Attacks against 
> DH512 are considered just feasible. However, for an attack the target 
> would have to re-use the DH512 private key, which is not recommended 
> anyway. Also applications directly using the low level API BN_mod_exp 
> may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e 
> (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).
>
> Go:
>
> CVE-2017-8932: arithmetic bug
>
> A bug in the standard library ScalarMult implementation of curve P-256 
> for amd64 architectures in Go before 1.7.6 and 1.8.x before 1.8.2 
> causes incorrect results to be generated for specific input points. An 
> adaptive attack can be mounted to progressively extract the scalar 
> input to ScalarMult by submitting crafted points and observing 
> failures to the derive correct output. This leads to a full key 
> recovery attack against static ECDH, as used in popular JWT libraries.
>
> CVE-2021-3114: underflow bug
>
> In Go before 1.14.14 and 1.15.x before 1.15.7, crypto/elliptic/p224.go 
> can generate incorrect outputs, related to an underflow of the lowest 
> limb during the final complete reduction in the P-224 field.
>

---

From: "Filippo Valsorda" <[email-masked]>
Date: Fri, 27 Aug 2021 18:40:52 +0200

2021-08-27 17:25 GMT+02:00 Rene Struik <[email-masked]>:
> 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 presented 19 years earlier (in 1999); (b) the attack requires many (100s) of reuses of the same private key string. Both the 1999 attack and your Blackhat 2018 version can be easily prevented if one uses blinded private keys.
> 
> 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 the CVEs by years (and sometimes decades) or in QA processes. E.g., with respect to (i), one had not gotten oneself into trouble if one had actually bothered to implement domain parameter checks. In the literature of implementation attacks, OpenSSL has proven to be an excellent "implementation security flaw paper generator".
> 
> I have yet to see evidence that ephemeral-static ECDH would be inherently insecure.

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 interesting to me.

Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it leads to Recommended: N in the registry.

>> The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file.
>> 
>> There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected.
>> 
>> There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem.
>> 
>> There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.
>> 
>> There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.
>> 
>> There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).
>> 
>> Go:
>> 
>> A bug in the standard library ScalarMult implementation of curve P-256 for amd64 architectures in Go before 1.7.6 and 1.8.x before 1.8.2 causes incorrect results to be generated for specific input points. An adaptive attack can be mounted to progressively extract the scalar input to ScalarMult by submitting crafted points and observing failures to the derive correct output. This leads to a full key recovery attack against static ECDH, as used in popular JWT libraries.
>> 
>> In Go before 1.14.14 and 1.15.x before 1.15.7, crypto/elliptic/p224.go can generate incorrect outputs, related to an underflow of the lowest limb during the final complete reduction in the P-224 field.
>>

---

From: Nimrod Aviram <[email-masked]>
Date: Fri, 27 Aug 2021 20:00:54 +0300

> The implementation guidance to avoid weaknesses in any ephemeral-static
exchange is "don't get anything wrong, anything at all
Agreed that it's not workable. I'm not sure there is existing and suitable
implementation guidance.
To avoid the Raccoon attack, one would have to implement the KDF such that
it is constant time, even for variable-length secrets. This is possible, at
least in principle, but I'm not aware of any implementation that does it or
plans to do it, and neither of any document that describes the complex
strategy for achieving this.

On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda <[email-masked]>
wrote:

> MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and
> server MUST NOT request them.  Would the working group support merging this
> The implementation guidance to avoid weaknesses in any ephemeral-static
> exchange is "don't get anything wrong, anything at all, all the way down to
> your field arithmetic libraries". I don't think that's a workable
> recommendation, and I believe we should deprecate modes that are so unsafe
> to implement.
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 27 Aug 2021 17:09:52 +0000

First, is this the only mode that has “directly linked vulnerabilities”? Second, cutting corners (e.g., for performance sake) by omitting domain parameters check, or not taking care of over/underflow, and such, cannot be considered a “protocol or algorithm fault”. Blame who you want, but the facts are here.

“MUST NOT”     => “if you do that, you’re not compliant, period”.

“SHOULD NOT” => “don’t do that, unless you have very good reasons, and can explain to your customers why it’s really OK in that particular case”.

Correct, both should lead to “Not Recommended”.

[snip] 

OpenSSL:

Go:

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Aug 2021 13:49:57 -0400

Hi Nimrod:

All the quoted Raccoon attack (of which you are a coauthor) does is 
highlight that poorly designed post-processing of a shared key 
(variable-size bit-string representation) could be used to extract 
secret info by solving an instance of the hidden number problem.

Let us not over-state the importance of this attack, though: the attack 
(for those who care) is easy to mitigate, e.g., as follows:
a) Let K be the derived shared key; let K1, ..., Kt be a set of keys 
including this key K (where this set has keys of byte-size L-1 and L, 
respectively, say L-1 once and L for all others);
b) Compute kj:=kdf(Kj) for all j=1,...,t;
c) Select select kj, where Kj corresponds to K.
Note: (if t:=2) if K has size L-1, set, e.g., K':=K xor random L-byte 
offset; if K has size L, set, e.g., K':=trunc_{L-1}(K) xor random 
{L-1}-byte offset.

Contrary to what you claim, this seems to be easy to implement in 
constant-time, however if not, this would still most likely thwart the 
attack (since one cannot apply the HNP any more {since one has to guess 
which leaks are real (correct j value) and which are spurious).

Bottom line (for me) is that one should not use attacks that are easy to 
mitigate as a pretext for deprecating things. There may be other reasons 
that have more merit, but the draft in the adoption call does not 
provide any of this. Hence, my feedback to reject the individual draft 
as it stands (based on lack of proper detail).

As Peter Gutmann already said in the thread, what problem is one trying 
to solve here???

Contrary to what Filippo suggests, I do think one should query why 
implementors do not heed advice that has been around for a long time (in 
that case, they should rightfully assume some blame). Implementors have 
duty of care too.

[my email of Aug 13, 2021, 9.58am EDT]

On 2021-08-27 1:00 p.m., Nimrod Aviram wrote:
> > The implementation guidance to avoid weaknesses in any 
> ephemeral-static exchange is "don't get anything wrong, anything at all
> Agreed that it's not workable. I'm not sure there is existing and 
> suitable implementation guidance.
> To avoid the Raccoon attack, one would have to implement the KDF such 
> that it is constant time, even for variable-length secrets. This is 
> possible, at least in principle, but I'm not aware of any 
> implementation that does it or plans to do it, and neither of any 
> document that describes the complex strategy for achieving this.
>
>
> On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2021-08-27 05:08 GMT+02:00 Joseph Salowey <[email-masked]
>     <mailto:[email-masked]>>:
>>     Thanks for all the discussion on this topic. There are several
>>     modes that TLS 1.2 can operate with respect to DH.  Below is a
>>     proposal on cases to merge some of the cases covered by this
>>     draft into the obsolete keyex draft.  I'd like to see if there is
>>     some consensus to make this change before we adopt it into the
>>     working group.
>>
>>     1. static-static where both client and server have DH
>>     certificates with long term keys.  I think we have general
>>     consensus that this mode should be a must not.  To deprecate this
>>     mode I think we need to state that clients MUST NOT use
>>     certificates of type rsa_fixed_dh and dsa_fixed_dh and server
>>     MUST NOT request them. Would the working group support merging
>>     this guidance into the obsolete keyex draft?
>>
>>     2. ephemeral-static where the client uses an ephemeral key and
>>     the server uses a long term key.  This mode does not provide
>>     forward secrecy.  I'm not sure we have reached consensus on how
>>     far to deprecate this option.  Would the working group support
>>     MUST NOT use these ciphersuites unless forward secrecy does not
>>     matter for your use case and any implementation guidance provided
>>     to avoid weaknesses is followed?
>
>     The implementation guidance to avoid weaknesses in any
>     ephemeral-static exchange is "don't get anything wrong, anything
>     at all, all the way down to your field arithmetic libraries". I
>     don't think that's a workable recommendation, and I believe we
>     should deprecate modes that are so unsafe to implement.
>
>>     On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         While static-static indeed do not provide forward secrecy
>>>         (and many of us – though not everybody! – carry for that),
>>>         static-ephemeral DH and ECDH are perfectly fine from that
>>>         point of view.
>>>
>>>
>>>
>>>         On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 -
>>>         MITLL <[email-masked] <mailto:[email-masked]>> wrote:
>>>>         *From:*TLS <[email-masked]
>>>>         <mailto:[email-masked]>> on behalf of Rene Struik
>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>         *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 easy to mitigate 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 or ff-based
>>>>         (e.g., sni, opaque), for which secure implementations are
>>>>         known. No detail is provided and that alone should be
>>>>>         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 sense
>>>>>         if the working group wants to adopt this draft (perhaps
>>>>>         the drafts could be merged if both move forward). Please
>>>>>         review the draft and post your comments to the list by
>>>>>         Friday, August 13, 2021.
>>>>>
>>>>>         Thanks,
>>>>>
>>>>>         The TLS chairs
>>>>>
>>>>>
>>>>         email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>>>         <https://www.ietf.org/mailman/listinfo/tls>
>>
>>     <https://www.ietf.org/mailman/listinfo/tls>
>>
>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 27 Aug 2021 11:01:46 -0700

On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda <[email-masked]>
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 interesting to me.
>

I agree. I can't think of a reason to list it as " Recommended: Y".

thanks,
Rob

---

From: Nimrod Aviram <[email-masked]>
Date: Sat, 28 Aug 2021 13:17:08 +0300

Hi Rene,

We are agreed on the strategy for mitigating Raccoon. We seem to disagree
on how easy it is to implement in constant time.
I'd like to understand your position better: Are you OK with implementers
reusing secret DH values without the above mitigation?
If not, it sounds like you suggest describing this mitigation strategy in
an RFC, and requiring it when DH secrets are reused, in the same vein the
Bleichenbacher mitigation is required. Is this your preferred course of
action?
If this is not your preferred course of action, could you please describe
what is? If you suggest leaving the situation as-is, I'd appreciate it if
you could please state so, so I could better understand your position.

best,
Nimrod

On Fri, 27 Aug 2021 at 20:50, Rene Struik <[email-masked]> wrote:

> (variable-size bit-string representation) could be used to extract secret
> info by solving an instance of the hidden number problem.
>
> that have more merit, but the draft in the adoption call does not provide
> any of this. Hence, my feedback to reject the individual draft as it stands
> (based on lack of proper detail).
>
> As Peter Gutmann already said in the thread, what problem is one trying to
> solve here???
>
>> Thanks for all the discussion on this topic.  There are several modes
>> that TLS 1.2 can operate with respect to DH.  Below is a proposal on
>> cases to merge some of the cases covered by this draft into the obsolete
>> keyex draft.  I'd like to see if there is some consensus to make this
>> change before we adopt it into the working group.
>>
>> 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
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
> --

---

From: Carrick Bartle <[email-masked]>
Date: Sat, 28 Aug 2021 17:29:37 -0700

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 <[email-masked]> wrote:
> 
> On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Carrick Bartle <[email-masked]>
Date: Sat, 28 Aug 2021 17:40:54 -0700

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: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.704.7932&rep=rep1&type=pdf

These attacks seem to me to indicate that ephemeral-static ECDH is inherently insecure. Do you disagree? If so, why?

> On Aug 27, 2021, at 8:25 AM, Rene Struik <[email-masked]> wrote:
> 
>> This is empirically disproved by a number of vulnerabilities that are exploitable (or near-misses for other reasons) only in ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 <https://eprint.iacr.org/2011/633> gives a good explanation of how these attacks work, and you might find https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf <https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf> interesting as well.
>> OpenSSL:
>>

---

From: Rob Sayre <[email-masked]>
Date: Sat, 28 Aug 2021 18:20:45 -0700

On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle <[email-masked]>
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

---

From: Carrick Bartle <[email-masked]>
Date: Sat, 28 Aug 2021 21:52:13 -0700

Sorry, I'm not sure what you mean?

> On Aug 28, 2021, at 6:20 PM, Rob Sayre <[email-masked]> wrote:
> 
> On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle <[email-masked] <mailto:[email-masked]>> wrote:
> Excellent. How much WG time should we waste on so-called "embedded" use cases?
> 
> thanks,
> Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Aug 2021 17:47:50 +0000

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 and then argue over it.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 30 Aug 2021 11:31:41 -0700

> 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 draft-bartle-tls-deprecate-ffdh-00 and
the expired draft-bartle-tls-deprecate-ffdhe-00 are similar I would expect
we would merge content from draft-bartle-tls-deprecate-ffdh-00 into
draft-aviram-tls-deprecate-obsolete-kex-00
with perhaps some addition text on certificates with static keys.

> 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.
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Aug 2021 19:08:22 +0000

Ack, of course.

My views are the same tho.

From: Joseph Salowey <[email-masked]>
Date: Monday, August 30, 2021 at 2:32 PM
To: Rich Salz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Mon, Aug 30, 2021 at 10:47 AM Salz, Rich <[email-masked]<mailto:[email-masked]>> 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 draft-bartle-tls-deprecate-ffdh-00 and the expired draft-bartle-tls-deprecate-ffdhe-00 are similar I would expect we would merge content from draft-bartle-tls-deprecate-ffdh-00 into draft-aviram-tls-deprecate-obsolete-kex-00 with perhaps some addition text on certificates with static keys.