Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
RFC 7525

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

(Jari Arkko) Yes

(Richard Barnes) (was Discuss) Yes

Comment (2015-02-18)
No email
send info
These COMMENTs are right on the edge of being  DISCUSS points, because I think there are some pretty critical references missing.  Please consider this a COMMENT of Unusual Strength.

Section 1. "which together are the most widely deployed ciphers"

Actually, at least in the web context, this isn't totally true.  According to Firefox telemetry, AES-GCM has been the most widely deployed cipher since at least 3Q14, and is currently used in the majority of TLS handshakes that Firefox does (52%) [1].

Section 3.1.1. Implementations MUST NOT negotiate SSL version 3

A reference to draft-ietf-tls-sslv3-diediedie seems in order here.

Section 3.1.

It would be good for this section to mention that servers MUST implement TLS version negotiation.  That is, they MUST NOT abort the handshake if the version offered by the client is higher than the version the server supports.  This is, after all, the root cause of fallback.  

Section 3.1.3. 

I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV here.  Did the WG discuss having any requirement for SCSV?

Also, if you want a cite for the 3% number, it's in the proceedings of IETF 91 [2].

Section 3.3.

You might point out HPACK [3] as an example of compression that is sensitive to things like CRIME.

Section 3.5.

Shouldn't this refer more specifically to draft-ietf-tls-session-hash [4]?  As it is, the recommendations in this section are kind of vacuous; e.g., TLS without session-hash provides no way to "bind the master secret to the full handshake".

Section 4.4. "Modular vs. Elliptic Curve"

I think that "finite field" or "modp" are more common than "modular".


Alissa Cooper (was Discuss) Yes

Comment (2015-02-20 for -10)
No email
send info
Thanks for handling my discuss and comments.

(Spencer Dawkins) Yes

Comment (2015-02-16 for -09)
No email
send info
This is great. Thanks for putting it together.

Just for my own edification, why would

   o  Implementations MUST support, and SHOULD prefer to negotiate,
      cipher suites offering forward secrecy, such as those in the
      Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie-
      Hellman ("DHE" and "ECDHE") families.

not also be "MUST prefer to negotiate"?

I found it strange that there's no hint of 

5.2.  Unauthenticated TLS and Opportunistic Security

   In summary: this document does not apply to unauthenticated TLS use

until about halfway through page 15. If it's important to say this, maybe it's better to say it earlier in the document?

(Stephen Farrell) Yes

Comment (2015-02-16 for -09)
No email
send info
I've a bunch of nits below. The only non-bit is whether or
not this has recently been compared to
Doing so again would be a fine thing if not.

- abstract & intro: nit: maybe s/and modes of
operation/and their modes of operation/ might be better,
as modes are defined by ciphersuites

- intro: maybe s/are/have been/ when you say CBC and RC4
are most common - that's changing fairly quickly

- intro: maybe s/will have/should have/ fewer vulns. when
deploying TLS1.3 - we can't control code quality

- 3.2: SSL stripping could do with a reference maybe

- 3.3: If it is true that compression attacks require the
attacker to control the traffic, then saying so would be
good, but only if there's an easily understood way to
phrase that, and I can't think of one right now;-)

- 3.6: add a reference to where SNI is defined (that's RFC
6066, section 3 I think?)

- section 4: would a reference to be good
here - they have specific configs one can use to implement
these recommendations (or at least I hope they do!)

- 4.1: I forget if the WG discussed adding a SHOULD NOT
for RSA key transport. I think that'd be a fine addition,
along with a statement that the justification is the lack
of PFS.

- 4.2.1: nitty, nit, nit: they MTI acronym should be
defined on 1st use, not 2nd:-)

- 4.4: "negotiated parameters" reads somewhat ambiguously
as it could be read to mean chinese menu, and I don't
think that's what you want

- 7.1: did anyone compare this text to the "most dangerous
code" paper? [1] [1]

- 7.3: "aka PKIX certificates" isn't correct, I'd delete
the phrase (but leave the ref to 5280) both times

Barry Leiba (was Discuss) Yes

Comment (2015-02-20 for -10)
No email
send info
Version -10 addresses all my comments; thanks very much for the work on this!

(Ted Lemon) Yes

Comment (2015-02-19 for -09)
No email
send info
Thank you _very_ much for doing this work!

(Kathleen Moriarty) Yes

Comment (2015-02-17 for -09)
No email
send info
Thanks for your work on this very helpful draft!

I just have a few comments/questions.

Section 5. Applicability statement:
Should this include application authors (mentioned in section 7.1) and Developers who can set the defaults for implementations of TLS to help operators that are mentioned in this applicability statement?  I see the sentence is phrased for 'deployment recommendations', but maybe this should also have a sentence or two on development recommendations.

Not for this draft, but this one raised a question for me.
Section 7.3: If you look at the following text:
   Unfortunately, many TLS/DTLS cipher suites were defined that do not
   feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256.  This
   document therefore advocates strict use of forward-secrecy-only
Should we be thinking about updates to the TLS registry to reflect this recommendation?  That's probably not this draft, but a follow on to provide the needed 'specification required'.  I'm sure a lot more thought might be needed for that and maybe support for features like PFS is added in a table if older recommendations that don't meet this are not removed.

HTTPbis went to the trouble of creating a blacklist of cipher suites that includes ones in the TLS registry.  They did take the MTI recommendation that is in this draft, which is good.  See section 9.2 and appendix A.

(Pete Resnick) Yes

(Alia Atlas) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Martin Stiemerling) No Objection