Thanks for putting together the -06 based on my preliminary comments, and my apologies for taking so long to get back to it. It turns out that going through the 80-odd documents we update takes a while!
I have a bunch of suggestions that are basically editorial, that I'll make a pull request for (along with suggested changes for several of the following comments). It's up at: https://github.com/tlswg/oldversions-deprecate/pull/3 We mention in the Abstract (but not Introduction!) that this document moves 2246 and 4346 (but not 6347!) to the historic state. Unfortunately, this is slightly problematic from a process perspective, since the current way to make things Historic (https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20) requires a separate "status change document" that gets its own IETF LC, to effectuate the status change. Most references to the status change document can be replaced by this RFC after it's published, but formally the move to historic is *not* done by this document. I've pulled into my pull request the language used in RFC 8429 to describe moves to Historic; please make sure to reproduce that language in the Introduction as well as the Abstract. I found three documents (3656, 4540, 7562) in the list of update targets that are on the ISE (not IETF) stream. I had talked to Adrian during my preliminary review, and in principle it is permissible to make those updates as part of this document, but we will need specific ISE approval to do so. I am supposed to sync up with him during IETF LC, but the document needs to be updated to clarify that the updates of ISE documents are/will be done with permission of the ISE. (Please also try to double-check that the list is complete; I didn't find an authoritative list of "all documents on the ISE stream" to grep against, and I didn't try to have something parse rfc-index.xml to output such a list. I note that in addition to our BCP 195 update (called out in Section 6), we also update 3552, which is BCP 72. This update is quite incidental (compared to our BCP 195 update), so it seems clear that having this document be part of BCP 195 is correct. Section 1.1 I went through all 83 of the references in the big list, that are supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0, as well as the shorter list of already-obsoleted documents. I won't bore you with my full notes, but there are some particular things that stood out from the review: - We have a separate list of updates for documents that are already obsolete (but don't say much about why we're going go the extra bother). However, three of the documents in our main list of updates (4743, 4744, and 6460) are already Historic, and presumably should be treated more like the already-obsolete ones. - Several documents (e.g., 8261, 5023) specifically have MUST-level requirements for 1.0 (or 1.1) that disappear or become internally inconsistent with our current update, so we might want to fill that void. - A few documents (6749, 6750, 6739) make an interesting claim about TLS 1.0 being the "most widely deployed version" and providing the "broadest interoperability". - Many documents note specific MTI ciphers (largely just the MTI ciphers from the respective TLS version). Since all ciphers defined for 1.0/1.1 also work in 1.2 (with the exception of the IDEA and DES ciphers from RFC 5469, that it claims "have been removed from TLS version 1.2"), these requirements in theory are still in effect, even though those particular ciphers are not great and the badness of those ciphers is a lot of the justification for deprecating the old protocol versions. I don't really think that a piecemeal effort to identify and update each specific MTI cipher mention is worth the effort, though it may be worth noting that TLS 1.2 has TLS_RSA_WITH_AES_128_CBC_SHA as MTI and that it is preferred over the older MTI ciphers. (Actually, it looks like a few of the specific MTI mentions in the documents we're updating are already TLS_RSA_WITH_AES_128_CBC_SHA, hooray.) - As implied by the previous bullet point, the IDEA and DES ciphers specified by RFC 5469 are now entirely obsolete, which means that that entire document is also obsolete (or maybe historic?). It seems like the right thing to do to effectuate that change via this document. - Similarly, the downgrade protection provided by the SCSV of RFC 7507 seems to be entirely obsolete. Any implementation that is compliant with this document will support only 1.2 or higher. If it only supports one version, no downgrade is possible; if it also supports 1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3 applies, so the SCSV mechanism is entirely redundant (i.e., obsolete). We could effectuate that status change in this document as well. - We list RFC 8465 as being updated, but it doesn't seem to say anything at all about TLS or reference the relevant RFCs. [RFC6614] has a requirement for TLSv1.1 although only makes an informative reference to [RFC4346]. The text in question seems to be: % * Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2 % [RFC5246]) is REQUIRED. [...] And RFC 5246 is a normative reference for it. So we may want to say "has a requirement for TLSv1.1 or later, although only makes an informative reference to [RFC4346]. This requirement is updated to be for TLSv1.2 or later." This document updates DTLS [RFC6347]. I note that in the thread from my preliminary review there was some support for the sentiment that these changes do not formally Update 6347, in that what 6347 says about version negotiation is still true; we just tell you not to do it. (https://mailarchive.ietf.org/arch/msg/tls/YUySQbMVJPv31Fwv68rEpcmBMsM/) But, if we do keep the Updates: relationship, I think we want to say slightly more, e.g., noting that the interoperation with DTLS 1.0 that it describes is now forbidden. Section 2 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 7457 [RFC7457] and other referenced RFCs. Although the attacks have Are the "other referenced RFCs" referenced from 7457 or from this document. This document references ... quite a few RFCs, so either way we should probably clarify. been mitigated, if support is dropped for future library releases for these versions, it is unlikely attacks found going forward will be mitigated in older library releases. [The wording here is kind of convoluted; I've suggested an alternative in the aforementioned pull request.] NIST for example have provided the following rationale, copied with permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History of TLS" (with references changed for RFC formatting). (The version of SP800-52r2 that we reference has been withdrawn. We should probably check that the quotation in question has not changed if we update to reference a current version of the NIST document.) Section 3 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker able to perform 2^77 operations, well below the acceptable modern security margin. The 2^77 number seems to be the pre-shattered.io number. Similarly, the authentication of the handshake depends on signatures made using SHA-1 hash or a not stronger concatenation of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash. Having reviewed the WGLC thread and the papers linked therefrom, I'm suggesting that we change this to "not appreciably stronger" (along with adding the missing article to "using SHA-1 hash"). In particular, https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf suggests that MD5 is particularly weak, and that attacking SHA-1 will continue to be the bulk of the work even as attacks on SHA-1 become more efficient than O(2^58), so that the difference is mostly just the factor of 64 for the Joux multicollision. Section 4 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of TLS MUST NOT be permitted. (editorial) I'm not sure how much precedent there is for a construction that talks about negotiating one version of TLS "from" some other version of TLS. In my head the negotiation is something that's done by or from an implementation, rather than a version. I don't want to insist on anything here, but I probably would have written something more like "negotiation of TLSv1.0 by any implementation of TLS MUST NOT be permitted". (And similarly for the following section.) Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be configured to prevent interception, though using the highest version available is preferable. This second sentence seems almost like it's undercutting the premise of MUST NOT use. Would it be better to say something like "While TLSv1.0 can be configured to prevent some types of interception, using the highest version available is preferred"? (Similarly for the following section.) Historically, TLS specifications were not clear on what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version could be selected to maximize interoperability, though no definitive value is identified as ideal. That guidance is still applicable; therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate TLSv1.0. This "MUST accept any value" seems redundant with Appendix D.2 of RFC 8446, which is also giving guidance in this space (but we don't currently link to). (Similarly for the following section.) Section 5 Should we also wrap the DTLSv1.0 bits in here? (Or have a dedicated section?) We don't currently have specific statements like "DTLSv1.0 MUST NOT be used", "MUST NOT send a ClientHello with ClientHello.client_version set to {254,255}", etc. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
