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.
- [TLS] AD Review of draft-ietf-tls-tls13 Kathleen Moriarty
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Kathleen Moriarty
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Russ Housley
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Russ Housley
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Kathleen Moriarty
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Russ Housley
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Kathleen Moriarty
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Kathleen Moriarty
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Dave Garrett
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Brian Smith
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Martin Thomson
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Ilari Liusvaara
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Sankalp Bagaria
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Dave Garrett
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Ilari Liusvaara
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Benjamin Kaduk
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Benjamin Kaduk
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Salz, Rich
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Yoav Nir
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Eric Rescorla
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Nico Williams
- [TLS] Better weak hash language (was Re: AD Revie… Dave Garrett
- Re: [TLS] Better weak hash language (was Re: AD R… Viktor Dukhovni
- Re: [TLS] Better weak hash language (was Re: AD R… Dave Garrett
- Re: [TLS] Better weak hash language (was Re: AD R… Viktor Dukhovni
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Bill Frantz
- Re: [TLS] AD Review of draft-ietf-tls-tls13 Ilari Liusvaara
- Re: [TLS] Better weak hash language (was Re: AD R… Nico Williams
- [TLS] Standard security levels (was Re: Better we… Nico Williams