Skip to main content

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
RFC 8422

Discuss


Yes

(Ben Campbell)

No Objection

Alvaro Retana
(Alia Atlas)
(Alissa Cooper)
(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.

Alvaro Retana No Objection

(Stephen Farrell; former steering group member) (was Yes) Discuss

Discuss [Treat as non-blocking comment] (2017-03-16 for -15)
Holding a Discuss so that comments get addressed.

(Ben Campbell; former steering group member) Yes

Yes (for -15)

                            

(Kathleen Moriarty; former steering group member) Yes

Yes (2017-03-14 for -15)
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 steering group member) No Objection

No Objection (2017-03-16 for -15)
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 steering group member) No Objection

No Objection (for -15)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -15)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -15)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -15)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -15)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -15)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -14)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -15)