IETF Logo Mail Archive

Re: [Dcrup] rsa-sha1 usage

Jim Fenton <fenton@bluepopcorn.net> Wed, 14 June 2017 03:20 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 37ACC12948B for <dcrup@ietfa.amsl.com>; Tue, 13 Jun 2017 20:20:50 -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 YUWYFSqjm8Ec for <dcrup@ietfa.amsl.com>; Tue, 13 Jun 2017 20:20:48 -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 9AB6F129473 for <dcrup@ietf.org>; Tue, 13 Jun 2017 20:20:48 -0700 (PDT)
Received: from splunge.local ([IPv6:2601:647:5500:1330:3d46:df10:69e2:448]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5E3Kkif022622 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dcrup@ietf.org>; Tue, 13 Jun 2017 20:20:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497410448; bh=qcXbMigaHBCg8tRN4Nh3ISiDJoazTVuRAm1HQR0bPxo=; h=Subject:To:References:From:Date:In-Reply-To; b=Mh4CjGqtDsnMkAR6/2ROu2dOgwgSjVBL8W2VidsEqdOMdY+Q5IptnU2s8fP0bdcbr /Rzg70PVBydfkbGA+iwQzrmEGVXbzsVW5MkkaXWKt1PcPHQBq5SOTNblTedIa4+7ql LuhzIEq1eKW6b7HCoIDdL/B0HZXahiSfrQOYwTgc=
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> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <CAL0qLwbFE5PzpOWzn-DwQ2D0z0=OAtEJLnwBbq2hk2SK2pc4Bg@mail.gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net>
Date: Tue, 13 Jun 2017 20:20:42 -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: <CAL0qLwbFE5PzpOWzn-DwQ2D0z0=OAtEJLnwBbq2hk2SK2pc4Bg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E9F0D02D1619807CED60CBBC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/89GsdgKyC1YvoFjAdKYMU6TrF4o>
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 03:20:50 -0000

On 6/13/17 8:16 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <fenton@bluepopcorn.net
> <mailto:fenton@bluepopcorn.net>> wrote:
>
>>     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.
>
>
> We can't have this logic both ways.  Scott claimed nobody pays
> attention to the advice in RFCs ("Operational practice​ isn't closely
> coupled with standards changes").  If that's true, then there's no
> meat to a MUST NOT anyway, and it really only matters what people will
> implement.  And if that's true, then saying current implementations
> neither sign with nor verify "rsa-sha1" because it's deprecated
> suffices, and we're done.

Based on no supporting data whatsoever, my conjecture is that
implementers pay a lot more attention to what RFCs say than people who
are deploying others' implementations. Which basically boils down to
MUSTs having a significant effect and SHOULDs having little. Which is
why I favor making signing with rsa-sha1 a MUST NOT prior to making
verification of rsa-sha1 signatures a MUST NOT.

-Jim

v2.43.4 | Report a Bug | By Email | System Status