Skip to main content

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-uta-tls-bcp-11

Yes

(Jari Arkko)
(Pete Resnick)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)

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

Alissa Cooper Former IESG member
(was Discuss) Yes
Yes (2015-02-20 for -10) Unknown
Thanks for handling my discuss and comments.
Barry Leiba Former IESG member
(was Discuss) Yes
Yes (2015-02-20 for -10) Unknown
Version -10 addresses all my comments; thanks very much for the work on this!
Jari Arkko Former IESG member
Yes
Yes (for -09) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (2015-02-17 for -09) Unknown
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
   ciphers.
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.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

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.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
Pete Resnick Former IESG member
Yes
Yes (2015-02-20) Unknown

                            
Richard Barnes Former IESG member
(was Discuss) Yes
Yes (2015-02-18) Unknown
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".



[1] http://mzl.la/1AmwXsm
[2] http://www.ietf.org/proceedings/91/slides/slides-91-saag-3.pdf
[3] https://tools.ietf.org/html/draft-ietf-httpbis-header-compression
[4] https://tools.ietf.org/html/draft-ietf-tls-session-hash
Spencer Dawkins Former IESG member
Yes
Yes (2015-02-16 for -09) Unknown
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
   cases.

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 Former IESG member
Yes
Yes (2015-02-16 for -09) Unknown
I've a bunch of nits below. The only non-bit is whether or
not this has recently been compared to bettercrypto.org.
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 bettercrypto.org 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]
http://dl.acm.org/citation.cfm?id=2382204

- 7.3: "aka PKIX certificates" isn't correct, I'd delete
the phrase (but leave the ref to 5280) both times
Ted Lemon Former IESG member
Yes
Yes (2015-02-19 for -09) Unknown
Thank you _very_ much for doing this work!
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

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

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

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

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown