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

[Salz, Rich]

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...@akamai.com>> 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.

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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 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.
>
>
>
> But yes, let’s adopt and merge in the expired keyex draft and then argue
> over it.
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

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 don't offer forward secrecy.
> 
> Excellent. How much WG time should we waste on so-called "embedded" use cases?
> 
> thanks,
> Rob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

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=rep1=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  wrote:
> 
> {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 
>>  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.
>> 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 
>> 

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

[Carrick Bartle]

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 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.
> 
> I agree. I can't think of a reason to list it as " Recommended: Y".
> 
> thanks,
> Rob
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

king 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 
>> wrote:
>>
>> >   which is a main reason cited for deprecating RSA
>> in draft-aviram-tls-deprecate-obsolete-kex.
>>
>> 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 <
>> u...@ll.mit.edu> wrote:
>>
>> >  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 <
>> u...@ll.mit.edu> wrote:
>>
>> I agree with Rene’s points.
>>
>> --
>> Regards,
>> Uri
>>
>>
>>
>> *From: *TLS  on behalf of Rene Struik <
>> 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
>> 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
>>
>> TLS@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>> --
>>
>> email: rstruik@gmail.com | Skype: rstruik
>>
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
> --
> email: rstruik@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

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

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

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rene Struik]

lto:cbartle...@icloud.com>> wrote:


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

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
mailto:u...@ll.mit.edu>> wrote:

> 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 mailto:u...@ll.mit.edu>> wrote:

I agree with Rene’s points.

-- 
Regards,

Uri


*From:*TLS mailto:tls-boun...@ietf.org>> on behalf of Rene Struik
mailto: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 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
TLS@ietf.org  <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls  
<https://www.ietf.org/mailman/listinfo/tls>



-- 
email:rstruik@gmail.com  <mailto:rstruik@gmail.com>  | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

___
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>


___
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>



___
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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.

 

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.

 

 

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

 

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

 

 

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

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 

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

[Nimrod Aviram]

> 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 
wrote:

> 2021-08-27 05:08 GMT+02:00 Joseph Salowey :
>
> 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 
> wrote:
>
> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
> 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 <
> u...@ll.mit.edu> wrote:
>
> >  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 <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
> --
> Regards,
> Uri
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> 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
> 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 

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

[Filippo Valsorda]

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

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

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

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


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 

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

[Blumenthal, Uri - 0553 - MITLL]

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.

 

Do we agree on “SHOULD NOT”?

 

 

On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:

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

 

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  
wrote:

 

>  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 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

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

 

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

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

 

-- 

email: rstruik@gmail.com | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

 

 

 

Attachments:

· smime.p7s

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Filippo Valsorda]

 
>>>>  
>>>> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
>>>>  wrote:
>>>>> I agree with Rene’s points.
>>>>>  
>>>>> -- 
>>>>> Regards,
>>>>> Uri
>>>>>  
>>>>>  
>>>>> *From: *TLS  on behalf of Rene Struik 
>>>>> 
>>>>> *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
>>>>>  
>>>>> 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
>>>>>> TLS@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>  
>>>>> 
>>>>> -- 
>>>>> email: rstruik@gmail.com | Skype: rstruik
>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>>>> ___
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>  
>  
> 
> *Attachments:*
>  * smime.p7s
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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. 

 

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.

 

 

On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:

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

 

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  
wrote:

 

>  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 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

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

 

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). 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
___

TLS mailing list

TLS@ietf.org

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

[Filippo Valsorda]

2021-08-27 05:08 GMT+02:00 Joseph Salowey :
> 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  wrote:
>>> >   which is a main reason cited for deprecating RSA in 
>>> > draft-aviram-tls-deprecate-obsolete-kex.
>>>  
>>> 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 
>>>  wrote:
>>> 
>>> >  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 
>>>  wrote:
>>>> I agree with Rene’s points.
>>>>  
>>>> -- 
>>>> Regards,
>>>> Uri
>>>>  
>>>>  
>>>> *From: *TLS  on behalf of Rene Struik 
>>>> 
>>>> *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
>>>>  
>>>> 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://dat

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

[Joseph Salowey]

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

On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle 
wrote:

> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
> 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 <
> u...@ll.mit.edu> wrote:
>
> >  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 <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
> --
> Regards,
> Uri
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> 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
> 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
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> email: rstruik@gmail.com | Skype: rstruik
>
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> >   which is a main reason cited for deprecating RSA in 
> > draft-aviram-tls-deprecate-obsolete-kex.
>  
> 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 
>  wrote:
> 
> >  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 
> mailto:u...@ll.mit.edu>> wrote:
>> I agree with Rene’s points.
>>  
>> -- 
>> Regards,
>> Uri
>>  
>>  
>> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
>> Rene Struik mailto: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 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
>>> TLS@ietf.org <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls 
>>> <https://www.ietf.org/mailman/listinfo/tls> 
>> 
>> -- 
>> email: rstruik@gmail.com <mailto:rstruik@gmail.com> | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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

And a very nice analysis, thank you!

>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. .  .  .  . So there's plenty of risk here and reasons 
> to stay away.

Correct. Agreed.

>Ephemeral-static DH makes a new derived key for each protocol 
> instantiation and
>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
>of confidentiality due to endpoint compromise.

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.

>In light of the above, it seems that your concerns are more focused on 
> "key reuse" than
>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.

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

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!


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dan Brown]

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.


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Loganaden Velvindron]

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 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.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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 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.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Tue, Aug 17, 2021 at 10:41 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

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

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

-Ekr


>
> >  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 <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> 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
> 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
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> email: rstruik@gmail.com | Skype: rstruik
>
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>  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 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

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

 

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). 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

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 
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.
>
> 2021-08-17 03:45 GMT+02:00 Joseph Salowey :
>
> 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 <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> 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
> 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

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

[Filippo Valsorda]

(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 :
> 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 
>  wrote:
>> I agree with Rene’s points.
>> __ __
>> -- 
>> Regards,
>> Uri
>> __ __
>> __ __
>> *From: *TLS  on behalf of Rene Struik 
>> 
>> *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
>> __ __
>> 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
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> __ __
>> 
>> -- 
>> email: rstruik@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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 <
u...@ll.mit.edu> wrote:

> I agree with Rene’s points.
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> 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
> 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
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> email: rstruik@gmail.com | Skype: rstruik
>
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

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

 

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). 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rene Struik]

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

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 
>  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 > <mailto:m...@lowentropy.net>> 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:
>>> 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/ 
>>> <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
>>> TLS@ietf.org <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> 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 anon (EC)DH ciphers are 
>> available with
>> TLS 1.3.
> 
> Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

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

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

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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 when you use it in TLS 1.3.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

Hi Martin,

Actually, a clarification question (more relevant to the other thread 
<https://mailarchive.ietf.org/arch/browse/tls/?q=Adoption%20call%20for%20Deprecating%20Obsolete%20Key%20Exchange%20Methods%20in%20TLS>
 : are you opposed to fully deprecating FFDHE? If so, why?


> On Jul 29, 2021, at 5:41 PM, Martin Thomson  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:
>> 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/ 
>> <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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

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  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:
>> 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/ 
>> <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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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:
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

  *   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!FlMZCO0a7tFKUtFIzYQuaGPHZKDkHN8YLu7ao9lNmCL1UYhg9sfLscTcrh8Z$>).

I support this draft as well, and the idea of merging them sounds good right 
now.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls