[TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

Benjamin Kaduk <kaduk@mit.edu> Sun, 26 July 2020 21:22 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1911E3A149E; Sun, 26 Jul 2020 14:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6JBvVqi27Ua; Sun, 26 Jul 2020 14:22:31 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0215A3A149D; Sun, 26 Jul 2020 14:22:27 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06QLMNad032641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Jul 2020 17:22:25 -0400
Date: Sun, 26 Jul 2020 14:22:23 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-tls-oldversions-deprecate.all@ietf.org
Cc: tls@ietf.org
Message-ID: <20200726212223.GY41010@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M>
Subject: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2020 21:22:40 -0000

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