Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 23 November 2019 13:40 UTC

Return-Path: <ilariliusvaara@welho.com>
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 B06DA1200D8 for <tls@ietfa.amsl.com>; Sat, 23 Nov 2019 05:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 h_5E4rBGP_fV for <tls@ietfa.amsl.com>; Sat, 23 Nov 2019 05:40:12 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528881200A1 for <tls@ietf.org>; Sat, 23 Nov 2019 05:40:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4118F237D3 for <tls@ietf.org>; Sat, 23 Nov 2019 15:40:08 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id wF1gXKhi9Tu0 for <tls@ietf.org>; Sat, 23 Nov 2019 15:40:07 +0200 (EET)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 87B552308 for <tls@ietf.org>; Sat, 23 Nov 2019 15:40:06 +0200 (EET)
Date: Sat, 23 Nov 2019 15:40:05 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20191123134005.GA1224585@LK-Perkele-VII>
References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> <CAF8qwaDoLGm+SjPE8T3UaQ0HY_M+EuU=GuWGaxGaPwvqCDKxgQ@mail.gmail.com> <fe0d54d8-a923-4a77-be9a-3b263d7efeb7@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <fe0d54d8-a923-4a77-be9a-3b263d7efeb7@redhat.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/akuoWOMlJjDxGfcitKaTWJD_gU0>
Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate
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: Sat, 23 Nov 2019 13:40:15 -0000

On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote:
> On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
> > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rsalz@akamai.com> wrote:
> > 
> > > > ...
> > > SHA-1 signature hashes in TLS 1.2" draft available
> > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.
> > > Please review the document and send your comments to the list by 2359 UTC
> > > on 13 December 2019.
> > > 
> > > I just re-read this.  Looks good. Perhaps a sentence of rationale in ...
> > 
> > To that end, the combination of client advice in sections 2 and 4 is a bit
> > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says
> > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would
> > the client include it in that case? It seems the two should either both be
> > MUST NOT or both be SHOULD NOT.
> 
> because it also influences certificate selection, and getting a certificate
> signed with SHA-1 isn't an automatically disqualifying property?
> (it may be an intermediate CA that's not used, it may be an explicitly
> trusted
> certificate, etc.)

If you don't want SHA-1 exchange signatures, you darn sure do not want
actual SHA-1 certificates that are not trust anchors anyway. And because
TLS 1.2 does not have separate lists for exchange signatures and
certificate signatures, the client needs to withdraw advertisment for
both in order to not send a misleading offer.

And I expect that in practice, not sending SHA-1 in
signature_algorithms would cause very little breakage on top of what
is already broken due to using SHA-1 exchange signatures.


So I think both should be MUST NOT.



-Ilari