Richard Barnes has entered the following ballot position for draft-ietf-uta-tls-bcp-09: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I really can't abide by the abdication in Section 5.2. Getting a cert is hard. Running reasonably recent software and configuring it properly is not. The possibility that a connection will not be authenticated is no excuse for using bad versions of TLS or using insecure ciphersuites. I appreciate that normally deference to WG consensus is appropriate, but this is a recommendation that could be actively harmful to the Internet by encouraging the continued use of broken code. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
