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

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

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

__

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

[Filippo Valsorda]

2021-08-27 15:13 GMT+02:00 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. 
>>  
>>  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?  
>>  
>> 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”.
>>  
>>  1. ephemeral-static where the client uses an ephemeral key and the server 
>> uses a long term key.  This mode does not provide forward secrecy.  I'm not 
>> sure we have reached consensus on how far to deprecate this option.  Would 
>> the working group support MUST NOT use these ciphersuites unless forward 
>> secrecy does not matter for your use case and any implementation guidance 
>> provided to avoid weaknesses is followed?
>> 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.

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

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

>  
>>  1. ephemeral-ephemeral  - I think these are already covered in the obsolete 
>> keyex draft. 
>> 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 

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

[TLS] progressing draft-ietf-tls-md5-sha1-deprecate

[Sean Turner]

Hi! While address the IoT Directorate comments from IETF LC, some addition 
comments have been received. I would like to address these new comments and get 
the I-D in the hands of the iESG. There were three set of comments:

1) Based on Daniels and David Benjamin’s reviews, the I-D is not as clear as it 
could be. The end result of deprecating MD5 and SHA1 is that 
signature_algorithms is always included; we should just say that. Chris has 
submitted the following PR to address this:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/19
You will notice that the PR removes section 6 of the I-D; it is unclear how 
much utility there is in updating the NOTE.

We are looking to merge this PR at the end of next week so please submit any 
comments before then.

2) Hannes suggested that we remove the 7525 updates text now that 7525bis is 
underway. I submitted this issue to capture the issue:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/17
Peter Saint-Andre (one of the 7525bis authors) has filled the following issue 
to incorporate the text from our I-D: 
https://github.com/yaronf/I-D/issues/245
Yaron has already merged the PR:
https://github.com/yaronf/I-D/pull/248
Chris has also kindly submitted this PR to remove the 7525bis-related text from 
“our" I-D:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/18

Again, we are looking to merge this PR at the end of next week so please submit 
any comments before then.

3) Hannes also had some editorial suggestions, that I created issues for:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/16
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/15
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/14
These are addressed in this PR:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/20

These ought to all be non-controversial, so we will merge them sometime next 
week.

Cheers,
spt (as Shepherd)
___
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]

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

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

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

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 Montgomery

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

[Rene Struik]

Hi Nimrod:

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


Let us not over-state the importance of this attack, though: the attack 
(for those who care) is easy to mitigate, e.g., as follows:
a) Let K be the derived shared key; let K1, ..., Kt be a set of keys 
including this key K (where this set has keys of byte-size L-1 and L, 
respectively, say L-1 once and L for all others);

b) Compute kj:=kdf(Kj) for all j=1,...,t;
c) Select select kj, where Kj corresponds to K.
Note: (if t:=2) if K has size L-1, set, e.g., K':=K xor random L-byte 
offset; if K has size L, set, e.g., K':=trunc_{L-1}(K) xor random 
{L-1}-byte offset.


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


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


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


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


[my email of Aug 13, 2021, 9.58am EDT]
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.


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



On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda > wrote:


2021-08-27 05:08 GMT+02:00 Joseph Salowey mailto:j...@salowey.net>>:

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
mailto:cbartle...@icloud.com>> wrote:


>

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