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

[TLS] tls-flags: abort on malformed extension

[Yoav Nir]

Hi.

To address Michael StJohns comment from 19-July, I submitted PR #12:

https://github.com/tlswg/tls-flags/pull/12 


What is says is that any implementation receiving a malformed tls_flags 
extensions should abort the handshake. The text provides a list (which I hope 
is comprehensive) of all the ways this specific extension can be malformed. 

Please comment here or on the PR is this makes sense to everybody.

Yoav

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

Hi Rene,

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

best,
Nimrod


On Fri, 27 Aug 2021 at 20:50, Rene Struik  wrote:

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