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

Benjamin Kaduk <kaduk@mit.edu> Mon, 11 November 2019 19:54 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 31DD1120823; Mon, 11 Nov 2019 11:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 AOPGiN-RtKOI; Mon, 11 Nov 2019 11:54:05 -0800 (PST)
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 BCBFD120A0D; Mon, 11 Nov 2019 11:53:30 -0800 (PST)
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 xABJrQ6j016427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 14:53:28 -0500
Date: Mon, 11 Nov 2019 11:53:25 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-tls-oldversions-deprecate.all@ietf.org
Cc: tls@ietf.org
Message-ID: <20191111195325.GE32847@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/XCO-RCyJyJqyQeUch-8TvnnPnmk>
Subject: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05
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: Mon, 11 Nov 2019 19:54:07 -0000

Hi all,

This is a "preliminary" review only because there's some strangeness
relating to the Updates: (and Obsoletes:) headers, and any changes there
would make me need to go and recheck the relationship of this document to
the ones listed.  So, I haven't done any of that yet, in an attempt to only
have to do it once.

Specifically, there's skew between the list of documents updated in the top
header and the list in Section 1.1.  Evern more annoyingly, the (tools)
HTML version seems to be missing some numbers from the document header,
that are present in the TXT version.  (Henrik is going to take a look, per
https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU .)

Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but
there is no "Obsoletes:" header at the top of the document.

I think nits is right about references (square-bracketed "[RFC6347]") in
the Abstract; we should change those to normal textual (parenthesed
"(RFC 6347)") before IETF LC.

Some other notes from a quick pass over the main text (though I'll probably
read it again once the above are addressed) follow.

Section 1

It feels a little backwards for a "primary technical reason" to
deprecate a protocol version being that "at least one widely-used
library has plans to drop [it]".

I do appreciate that we give discussion about what we intend
"deprecation" to mean and for whom -- thank you for that!

Section 2

      TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant
      change to TLS that aims to address threats that have arisen over
      the years.  Among the changes are a new handshake protocol, a new
      key derivation process that uses the HMAC-based Extract-and-Expand
      Key Derivation Function (HKDF), and the removal of cipher suites
      that use static RSA or DH key exchanges, the CBC mode of
      operation, or SHA-1.  The list of extensions that can be used with
      TLS 1.3 has been reduced considerably.

While it's true that the initial list of extensions usable with TLS 1.3
is smaller than the list of extensions usable at TLS 1.2 taken at the
same time, it's also true that the requirements for allocating a new
extension codepoint have been reduced dramatically.  So I think I'd say
that this reflects not a desire to reduce the attack surface (as
"measured" by number of extensions) but rather a paradigm shift in how
the protocol works, which leaves some existing functionality
incompatible with the new model.  I don't really get a clear sense of
what this current last sentence is trying to say (i.e., whether it's one
of those two descriptions I offered above).

Section 3

   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.

My recollection of the WG discussions (which I will go review) is that
we don't really have consensus on the "not stronger" portion of this.
Is that a key component of the document here?  (N.B. this is *not* an
invitation to rehash that discussion again!  The chairs or I can provide
a summary of points not resolved by previous discussion and points
believed to be adequately agreed upon, which would be a trigger for any
additional discussion that might be needed.)

Thanks for putting this document together (I know that getting all the long
list of references/updates/etc. right is really tedious and frustrating),
and sorry to have been sitting on it for so long.

-Ben