Skip to main content

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
draft-ietf-tls-rfc4492bis-17

Discuss


Yes

(Ben Campbell)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 14 and is now closed.

Stephen Farrell Former IESG member
(was Yes) Discuss
Discuss [Treat as non-blocking comment] (2017-03-16 for -15) Unknown
Holding a Discuss so that comments get addressed.
Ben Campbell Former IESG member
Yes
Yes (for -15) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (2017-03-14 for -15) Unknown
Thanks for your work on this draft.  I just have one question:

In section 5.10, I see the following text:
   The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
   function, such as one of the new SHA hash functions specified in FIPS
   180-2 [FIPS.180-2], SHOULD be used instead.

Why are you setting the default to SHA-1 and then recommending that something else should be used?  Why not just start with a different SHA hash function as the default or at least for TLS 1.2?  I do see the prior text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended to go right to TLS 1.2 with the SSLv3 deprecation.  As such, I'm not clear on why the SHA-1 default.
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-03-16 for -15) Unknown
I would like to vote Yes on this document, but there are some minor issues with this document which prevent me from doing so:

0) There is some general awkwardness in text talking about allowed points formats, considering that only uncompressed form is now allowed. I don't have recommendations about improving text, other than the following:

If no future formats are expected, it feels almost better to recommend against inclusion of the Point formats extension, as lack of it means uncompressed format anyway.

1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3 or does it also apply to 2.1 and 2.2? If the latter, then it needs to be moved to section 2.

2) In Section 6:

   Server implementations SHOULD support all of the following cipher
   suites, and client implementations SHOULD support at least one of
   them:

   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

GCM ciphers are not listed in the table earlier in the same section. They are defined in RFC 5289. This document doesn't have any reference to RFC 5289 and GCM ciphers are not discussed anywhere else in the document.
Alia Atlas Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -15) Unknown