Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

Dave Garrett <davemgarrett@gmail.com> Sat, 11 July 2015 20:05 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7D1AC43B for <tls@ietfa.amsl.com>; Sat, 11 Jul 2015 13:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 8VHPHaM3aSJZ for <tls@ietfa.amsl.com>; Sat, 11 Jul 2015 13:05:03 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02081AC439 for <tls@ietf.org>; Sat, 11 Jul 2015 13:05:03 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so33067575qkd.3 for <tls@ietf.org>; Sat, 11 Jul 2015 13:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=/D3rN/twAYmf7wSLojn7tfBWZk13DVFKEdrOhiTIE54=; b=q5s9MMFI8+dvlwYc1048yBfQevSzHLkyIf8N4cMj7F0vfmi2NIR35N3OOIn6PcDrps V1RN6m9/pB5ppb+XL50FX0KyKDrRs+onq6Y71B7YC1aRe1mSsOwbdyEvdwU9FXL8xAp0 /SO1nUp82pksbj5OyKCFS0jC/UDtoG6Cisq3jy9DTDzeLyHvAN+CIpauL3ca543LR3e4 I7dPQK8ezPlpxfv/itlMMYVvKLQgqcVOVtr+OR3r3VTUKz+q6U4lmQn2b5LuZi90fYin dPx0pYQtQfmJ8Uy9pTegfB+/5N5GSKkilCr0yHekdTtNHcqiMZlrirjUlt6Zeyug++IP Hk7g==
X-Received: by 10.140.89.197 with SMTP id v63mr11456511qgd.97.1436645102982; Sat, 11 Jul 2015 13:05:02 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id z81sm7889263qkg.44.2015.07.11.13.05.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 Jul 2015 13:05:02 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Viktor Dukhovni <ietf-dane@dukhovni.org>
Date: Sat, 11 Jul 2015 16:05:01 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CALuAYvbteowTeyWe9VneRHgyvzTRS3LfKdorWt=jmEy2k+wNqw@mail.gmail.com> <20150711190040.GS28047@mournblade.imrryr.org> <201507111536.50433.davemgarrett@gmail.com>
In-Reply-To: <201507111536.50433.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201507111605.01407.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JViRuIYLmlOOW53JiLvztmUTDuA>
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Jul 2015 20:05:05 -0000

Ok, revised:

========================================
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server SHOULD be signed by a hash/signature
algorithm pair indicated by the extension (or defaults assumed in its
absence). If the server cannot produce a valid certificate chain using
these known supported pairs, then it SHOULD send the client a complete
valid chain which attempts to match known support where possible, yet
including certificates that are not known to be supported. If the
client cannot build a trusted chain using these certificates and any
other trusted information it has access to, then it MUST send an
"unsupported_certificate" alert message and close the connection.
========================================

Comments?

Note that for the purposes of discussion here, opportunistic encryption can "trust" whatever it wants; anything or nothing, depending on implemented strategy.


Dave