Subject: Re: [Uta] Comments on draft-ietf-uta-tls-bcp-07

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 19:33:52 -0700

On 11/21/14, 9:24 AM, Paul Hoffman wrote:
> On Nov 20, 2014, at 9:40 PM, Joseph Salowey <[email-masked]> wrote:
>> "The named curve registry contains 160-bit elliptic curves which are considered to be roughly equivalent to only an 80-bit symmetric key [ECRYPT-II].   The use of curves of less than 192-bits is NOT RECOMMENDED."
>
> Good catch, and this should be added to the text.

Agreed.

>> In the last paragraph the use of the term fingerprint seems odd and perhaps misleading.  I think the term hash algorithm would be better:
>>
>> "the use of the SHA-256 hash algorithm is RECOMMENDED"
>
> Yep.

Agreed.

>> 2.  Section 4.4
>>
>> The rational section makes it sound like there is limited support for ECDHE.  I think this is changing quite rapidly and we should be promoting ECDHE suites more.  Also, I've also run into some folks who are under the misconception that using ECC cipher suites require the use of ECDSA certificates.  In addition, I think the document should mention that many DHE implementations also have security issues with validating group parameters (this is mentioned in the attacks draft, but it might also be good to reference it here).
>>
>> Suggestion for rational in section 4.4:
>>
>> "Rationale: Although Elliptic Curve Cryptography is widely deployed there are some communities where its uptake has been limited for several reasons, including its complexity compared to modular arithmetic and longstanding perceptions of IPR concerns (which, for the most part, have now been resolved [RFC6090]). Note that ECDHE cipher suites exist for both RSA and ECDSA certificates so moving to ECDHE cipher suites does not require moving away from RSA based certificates.  On the other hand, there are two related issues hindering effective use of modular Diffie-Hellman cipher suites in TLS:
>>
>> o There are no protocol mechanisms to negotiate the DH groups or parameter lengths supported by client and server.
>>
>> o There are widely deployed client implementations that reject received DH parameters if they are longer than 1024 bits. In addition, several implementations do not perform appropriate validation of group parameters and are vulnerable to attacks referenced in section 2.9 of [UTA-Attacks]."
>
> That seems like a good addition, but it might be controversial. If the latter is true, we can wait for a revision.

So that we all understand the proposal, Joe is suggesting the following 
change...

OLD

    Rationale: Elliptic Curve Cryptography is not universally deployed
    for several reasons, including its complexity compared to modular
    arithmetic and longstanding perceptions of IPR concerns (which, for
    the most part, have now been resolved [RFC6090]).  On the other hand,
    there are two related issues hindering effective use of modular
    Diffie-Hellman cipher suites in TLS:

    o  There are no protocol mechanisms to negotiate the DH groups or
       parameter lengths supported by client and server.

    o  Many servers choose DH parameters of 1024 bits or fewer.

    o  There are widely deployed client implementations that reject
       received DH parameters if they are longer than 1024 bits.

NEW

    Rationale: Although Elliptic Curve Cryptography is widely deployed
    there are some communities where its uptake has been limited for
    several reasons, including its complexity compared to modular
    arithmetic and longstanding perceptions of IPR concerns (which, for
    the most part, have now been resolved [RFC6090]). Note that ECDHE
    cipher suites exist for both RSA and ECDSA certificates so moving to
    ECDHE cipher suites does not require moving away from RSA based
    certificates.  On the other hand, there are two related issues
    hindering effective use of modular Diffie-Hellman cipher suites in
    TLS:

    o There are no protocol mechanisms to negotiate the DH groups or
      parameter lengths supported by client and server.

    o There are widely deployed client implementations that reject
      received DH parameters if they are longer than 1024 bits. In
      addition, several implementations do not perform appropriate
      validation of group parameters and are vulnerable to attacks
      referenced in section 2.9 of [UTA-Attacks]."

I don't agree with removing the second bullet, but the rest seems 
relatively uncontroversial to me.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Brian Smith <[email-masked]>
Date: Mon, 1 Dec 2014 22:57:28 -0800

> OLD

<snip>

>       received DH parameters if they are longer than 1024 bits.

<snip>

> I don't agree with removing the second bullet, but the rest seems relatively
> uncontroversial to me.

Peter,

I believe that Joe's suggested text was written before the second
bullet was added. The second bullet was added during this final WGCL
in response to a request by myself. In other words, this is just a
merge conflict, which is best resolved by merging the second bullet
into Joe's suggested text.

Cheers,
Brian

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 2 Dec 2014 09:12:13 -0800

> into Joe's suggested text.
[Joe] I'm OK with the second bullet.  I'm not sure if it was not there when
I reviewed it or if I left it out for not good reason I can think of.

> Cheers,
> Brian
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 02 Dec 2014 17:26:37 -0700

On 12/2/14, 10:12 AM, Joseph Salowey wrote:
>
>
> On Mon, Dec 1, 2014 at 10:57 PM, Brian Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Peter Saint-Andre - &yet <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > OLD
>
>     <snip>
>
> [Joe] I'm OK with the second bullet.  I'm not sure if it was not there
> when I reviewed it or if I left it out for not good reason I can think of.

Joe, thanks for the clarification.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Dec 2014 02:01:59 -0500

>      parameter lengths supported by client and server.

Well, it's not finished with standardization or deployment yet, but
there is:

https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe

I agree that implementations lacking this mechanism have a good reason
to avoid using finite field DH.

fwiw, i suspect we should also the term "finite field Diffie-Hellman
cipher suites" instead of "modular Diffie-Hellman cipher suites", since
elliptic curves are also modular.

	--dkg

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sat, 06 Dec 2014 19:49:39 -0700

> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe

OK, so "There are no standardized, widely implemented protocol 
mechanisms"...

> elliptic curves are also modular.

Noted!

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/