Hi all,
For some reason Joe's post didn't get to the list so I'm just forwarding that whilst someone figures out what is/was up. Please cc' Joe on responses just in case he's not seeing list traffic. Cheers, S. >From [email protected] Fri Nov 14 13:14:42 2014 Date: Fri, 14 Nov 2014 13:14:42 -0500 (EST) From: joe <[email protected]> To: [email protected] Cc: [email protected] Subject: Feedback on draft-ietf-uta-tls-bcp-07 Hi, Following discussions with some colleagues, I was encouraged to directly share feedback on draft-ietf-uta-tls-bcp-07 with UTA. That feedback is enclosed below for your consideration. Section 1., top of page 3 in the text version: "These are minimum recommendations for the use of TLS in the vast majority of implementation and deployment scenarios" At least in some parts of the draft, specific recommendations are offered, and I am concerned that rather than being read as establishing a minimum floor, those recommendations may be taken as narrowly defining the ONLY acceptable specification. I'd urge that *stronger* options always be explicitly allowed, since different users will often have different priorities when it comes to cryptographic strength vs. computational loads, etc. Section 3.1.1 Totally agree with efforts to get SSLv2 and SSLv3 gone. Would like to ALSO see TLS 1.0 and TLS 1.1 treated equally strongly (e.g., change the "SHOULD NOT negotiate TLS verison 1.0" and change the "MAY negotiate TLS version 1.1" to "MUST NOT") If you're NOT doing TLS 1.2, you lose the ability to employ AES GCM/AES CCM, you lose HMAC-SHA256/SHA-384 and AEAD, and given that TLS 1.1 dates from April 2006 and TLS 1.2 dates from August 2008, I think the time has come to pull the plug on TLS 1.1. Six years is enough time for TLS 1.2 to gain adoption, and if penetration isn't yet where it should be, the time has come to push on that a bit. I'd also note, as the draft itself comments, "the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2." So, let's not backslide/compromise on TLS 1.1 :-) 3.1.2: Consistent with the preceding comments, I'd like to see only Version 1.2 of DTLS listed as acceptable. 3.1.3: If you're only doing TLS 1.2, the fallback scenario is inherently dealt with 3.2: I strongly support HSTS. However, I'd encourage you to to reference the Proxy User Stories page at https://github.com/http2/http2-spec/wiki/Proxy-User-Stories outlining some of the issues that can arise in a proxy-incompatible Strict TLS environment so that folks can make a fully-informed decision. Should there be a recommendation around max-age? HSTS also relies on the browser maintaining data on what sites are using HSTS. Should there be recommendations to browser authors around maintaining the integrity of that data? Currently the process of overriding HSTS state is trivially accomplished for major browsers (see for example http://classically.me/blogs/how-clear-hsts-settings-major-browsers) 4.2: This section recommends: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 I agree with those recommendations. However, are those cipher suites listed in *recommended* order? 4.2.1 states that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SHOULD be the first cipher proposed, and servers SHOULD prefer that cipher whenever is proposed. I'd prefer to see the AES_256 version recommended instead, given that it provides a large margin of cryptographic strength. Also in 4.2.1, NIST P-256 (secp256r1) is called out for interoperability purposes. I get the intent, but I have concerns given the analysis reported near the bottom of http://safecurves.cr.yp.to/ for that (and related) curves. I would like to see a more complete discussion of ECC curve selection criteria. 4.3: Currently recommends at least 2048 bit DH parameters and certificates. I'd prefer to see 4096 bit DH parameters and 4096 bit certificates explicitly recommended. (Rationale: industry efforts to move to SHA-2 for hashes should be supported by proportionately strong symmetric and asymmetric key lengths, as nicey summarized at http://www.keylength.com/en/compare/ ) Should there be recommendations around the dhparam generator, too? E.G., openssl supports 2 and 5 -- which should be used, and why? I'd also suggest that the realities of plans for deprecating SHA-1 certs in popular browsers means that use of SHA-2 (including EITHER SHA-256 *OR* SHA-384) is now effectively necessary for sites that want to have their certs be globally trusted. Thus, RECOMMENDING use of SHA-256 should be strengthened to MUST USE and EITHER SHA-256 *OR* SHA-384 should be permitted. 7. Security considerations section: often this is a proforma section included merely to meet RFC formatting requirements, and many readers may be in the habit of "tuning out" by the point they hit that section. In the case of this draft, however, important content is included in section 7. I would urge that it be moved up in the document to a more prominent location. The approaches for obtaining access to a private key (at the bottom of page 14/top of page 15) omit an important process: subornation of a system administrators through bribery, coercion, etc., or collection of private keys from inadequately protected backups. 7.5: Certificate revocation. This section could be succinctly summarized as "revocation s*cks." However, revocation is still a critically important protection. From a practitioners POV, CRL and OCSP are widely supported by CAs and many browsers, and should not be summarily given the RFC equivalent of a shrug of the shoulders. They aren't perfect, but they do offer some ability to communicate revocation status *IF* browsers and other clients check them. That said... More emphasis should be put on the privacy implications of relying on OCSP, *AND* use of OCSP should be flagged as a potential denial of service attack (a down or unreachable OCSP responder from a major CA tends to result in a real "fire drill") I would also note that when clients aren't yet connected to the Internet (e.g., prior to wireless auth for example), they often lack the ability to reach OCSP responders or the ability to download CRLs, yet they often need to evaluate the revocation status of a certificate they've been presented for use in establishing that connection, potentially resulting in a troublesome circularity. Other: should there be discussion of certificate chains? Specifically, some implementations want intermediate certs in order from closest to the root to furthest from the root, while others reverse that order. I'd like to see that order normalized. No discussion of SPDY. Given that TLS can impose a performance hit, I think it would be worth at least touching on the impact that SPDY can have as an offsetting factor. And as a practical matter, given the technical complexity involved in configuring systems to meet all the recommendations in the draft, should there be endorsement of use of automated assessment tools for the purpose of confirming appropriate system configurations? Thanks for considering this feedback on a very important draft. Regards, Joe Joe St Sauver, Ph.D. ([email protected] or [email protected]) Farsight Security, Inc. https://www.stsauver.com/joe/ _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
