Re: [Dcrup] rsa-sha1 usage

Jim Fenton <fenton@bluepopcorn.net> Wed, 14 June 2017 01:56 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1A12957B for <dcrup@ietfa.amsl.com>; Tue, 13 Jun 2017 18:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 t2U2uNlUTMyu for <dcrup@ietfa.amsl.com>; Tue, 13 Jun 2017 18:55:58 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 CB5FE126DCA for <dcrup@ietf.org>; Tue, 13 Jun 2017 18:55:58 -0700 (PDT)
Received: from splunge.local ([IPv6:2601:647:5500:1330:90f4:2421:52d:e0c9]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5E1tqfD021648 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dcrup@ietf.org>; Tue, 13 Jun 2017 18:55:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497405358; bh=mgPPXOe+hCECP4nqIsKU3JiApaX7MygJgyspW7OYz2s=; h=Subject:To:References:From:Date:In-Reply-To; b=G3SRPuCpIls40GrxXbEPQUSy/JgznkDNJbz+bPTiLw1/iKueYksQzz9N3R5iom80C CoocpmsW4bWAtfGOpDo7T9rfOTpk+/zD8egq3NyRskJwga1mWV7UndF+xUa4dom+fn uHCPdSjwcyINSdd8aitAlDZM9uxBGlUR+9Y+8CtQ=
To: dcrup@ietf.org
References: <m38tkw53bd.fsf@carbon.jhcloos.org> <CABa8R6s6rzc+Ky8sLWcK7NtforSksEhNRkWVeF=k1v8GC80knw@mail.gmail.com> <m3wp8gpx20.fsf@carbon.jhcloos.org> <CAOj=BA2O+Hf2VGOtbmnqY2M5J9u8uJ7wm7SxEW551SXBwDdanw@mail.gmail.com> <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <aa52134a-ac20-bd70-8834-1598a8eaa536@bluepopcorn.net> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <CAL0qLwaqPwb+cNhRCWLBp2qjTWtS65JAvstc9GfrhDDXRv+d6w@mail.gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net>
Date: Tue, 13 Jun 2017 18:55:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwaqPwb+cNhRCWLBp2qjTWtS65JAvstc9GfrhDDXRv+d6w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C65B212E04DCF1FE0E40FAA4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/E7Dso7rPgs_gMCNuIZht4uvaqUI>
Subject: Re: [Dcrup] rsa-sha1 usage
X-BeenThere: dcrup@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DKIM Crypto Update <dcrup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrup>, <mailto:dcrup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup/>
List-Post: <mailto:dcrup@ietf.org>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrup>, <mailto:dcrup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 01:56:00 -0000

On 6/13/17 6:40 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <sklist@kitterman.com
> <mailto:sklist@kitterman.com>> wrote:
>
>     I think your proposed remedy is too mild though.  Given the degree
>     to which the SHOULD NOT sign rsa-sha1 has been ignored for the
>     last decade, I don't believe anything other than MUST NOT
>     sign/MUST NOT verify rsa-sha1 is very useful.
>
But it isn't a simple SHOULD NOT, because it's followed by:

INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
      senders might prefer to use rsa-sha1 when balancing security
      strength against performance, complexity, or other needs.  In
      general, however, rsa-sha256 should always be used whenever
      possible.


Basically this seems to be giving signers an out to use rsa-sha1 because
performance of rsa-sha256 is worse (although I doubt that it is
significantly so). Granted, I'm probably reading a lot more nuance into
the specification than many readers are.
>
> That being the case, why do we think people will pay attention to a
> MUST NOT today?

Because implementations will stop supporting rsa-sha1, forcing the issue
for any who upgrade. I'm all for having them stop supporting signing
with rsa-sha1, but they should continue to support verification for a while.

-Jim