Re: [TLS] AD Review of draft-ietf-tls-tls13

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 19 May 2017 20:51 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 BB7D0129B19 for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 VEq1vd-DxMkg for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:51:23 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C8D129B45 for <tls@ietf.org>; Fri, 19 May 2017 13:51:22 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 24F557A32F1 for <tls@ietf.org>; Fri, 19 May 2017 20:51:22 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAPZZOTgizE2n06V9wEtARFCXB7FP_eikW-K1k67bZG11kNhSAw@mail.gmail.com>
Date: Fri, 19 May 2017 16:51:21 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
References: <CAPZZOTgizE2n06V9wEtARFCXB7FP_eikW-K1k67bZG11kNhSAw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OMzWYbPe1TrovqT8PgAdg6d39gI>
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 19 May 2017 20:51:25 -0000

> On May 19, 2017, at 5:34 AM, Sankalp Bagaria <sankalp.nitt@gmail.com> wrote:
> 
> I would like to mention that TLS can be used with non-X.509 certificates also.
> In particular, it can be used with ITS ETSI and IEEE certificates. 
> https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609
> 
> So, in my opinion, TLS should be very loosely or not at all coupled with 
> RFC 5280.

Which brings us to some more undesirable layer violation in the current
draft.  The language in question is appropriate for updates to RFC5280,
but does not belong in TLS.  The problems in question are largely
already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
certificates, browsers no longer support them, ...) and continue to
be further remediated in the appropriate standards and products.

Therefore delete:

   Section 4.2.3 (Legacy algorithms paragraph final sentence):

      ...                                       TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

   Section 4.4.2.2:

   ...          This fallback chain MAY use the deprecated SHA-1 hash
   algorithm only if the "signature_algorithms" extension provided by
   the client permits it.  If the client cannot construct an acceptable
   chain using the provided certificates and decides to abort the
   handshake, then it MUST abort the handshake with an
   "unsupported_certificate" alert.

   Section 4.4.2.4:

   Any endpoint receiving any certificate signed using any signature
   algorithm using an MD5 hash MUST abort the handshake with a
   "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
   that any endpoint receiving any certificate signed using any
   signature algorithm using a SHA-1 hash abort the handshake with a
   "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
   to SHA-256 or better as soon as possible to maintain interoperability
   with implementations currently in the process of phasing out SHA-1
   support.

I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
or even MD5.

Opportunistic unauthenticated TLS ignores the peer certificate and should
not have to fall back to cleartext just because some certificate in the
chain is not sufficiently sexy.  There are other legitimate use cases where
the restrictions above are inappropriate.

The reason I am pointing this out is that I just had to waste a bunch of
time convincing the rest of the OpenSSL team to ignore the draft language
in question, and just stick with whatever "security level" (floor on
algorithm strength) the application or default settings requested.  This
already excludes MD5 by default, and we'll likely adjust the collision
resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from
the recent Google collision announcement), after which SHA-1 will also
be excluded at security level 1.  This will be done in the X.509 ala PKIX
code and not the TLS code, and applications that ignore the chain or do
DANE-EE(3), ... will not be affected.

I propose that the current draft language is just a landmine for TLS
implementations, that addresses a non-problem (or more precisely a
problem that is more properly and well addressed elsewhere).

-- 
	Viktor.