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

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 Nov 2014 21:40:28 -0800

I've read through draft-ietf-uta-tls-bcp-07 and it looks pretty good.
I have a few minor comments:

1.  Section 4.3

This section recommends key lengths for modular DH keys, but is silent on
ECDH keys.   The Named Curve Registry has 160-bit curves which should be
avoided.   We should probably recommend that elliptic curves of at least
192 bits be used (some folks might argue for 224 bits here).

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

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"

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 <https://tools.ietf.org/html/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]."

Cheers,

Joe

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Nov 2014 09:59:18 +0100

> I have a few minor comments:

Given that we are at the last day of the WGLC the WG needs to be
explicit about support (or lack there of).

Your +1/-1 are much appreciated!

	Cheers Leif

> 
> 1.  Section 4.3 
> 
> This section recommends key lengths for modular DH keys, but is silent
> on ECDH keys.   The Named Curve Registry has 160-bit curves which should
> be avoided.   We should probably recommend that elliptic curves of at
> least 192 bits be used (some folks might argue for 224 bits here).  
> 
> In the last paragraph the use of the term fingerprint seems odd and
> perhaps misleading.  I think the term hash algorithm would be better:
> 
> 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).   
> 
> "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 <https://tools.ietf.org/html/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]."
> 
> 
> Cheers,
> 
> 
> Joe
> 
> 
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 21 Nov 2014 12:07:47 +0100

>> I have a few minor comments:
Good comments!

> Your +1/-1 are much appreciated!

-1. Publish the document before it becomes irrelevant. As mentioned
before; it can be updated at any time.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 21 Nov 2014 16:11:11 +0100

>>> I have a few minor comments:

Was asked to clarify on that. Joeseph's comments are very useful I
think, but should be incorporated into later versions/updates of the
document in question.

Sorry for any confusion that I may have caused :)

Aaron

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Nov 2014 08:24:22 -0800

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.

> In the last paragraph the use of the term fingerprint seems odd and perhaps misleading.  I think the term hash algorithm would be better:
> 

Yep.

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

--Paul Hoffman

---

From: Leif Johansson <[email-masked]>
Date: Sat, 22 Nov 2014 14:16:25 +0100

>> "the use of the SHA-256 hash algorithm is RECOMMENDED"

Still only one voice of support for this change. Consensus is rough to
the point of almost being absent.

Any strong opinions from the authors? AFICT this is the final issue
before we close the WGLC

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 22 Nov 2014 13:56:49 +0000

> the point of almost being absent.

I think the changes above are fine to make if changes are being done.

I didn't post before because I thought they should be uncontroversial
not because I didn't support the changes. (And I'd also trust you chairs
to identify such uncontroversial changes without each one getting a load
of +1's - if you judge them so and say that to the list, then we get a
chance to object if we think you've called it wrong. And then there's
IETF LC etc. afterwards anyway.)

S.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 22 Nov 2014 15:06:08 +0100

> IETF LC etc. afterwards anyway.)

thx

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2014 08:29:36 -0500

I agree with Joe's comments.

Steve