Return-Path: 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 35B5A129AEA for ; Tue, 13 Jun 2017 20:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M7Aw4P7Ti-P0 for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 520F012957B for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q15so87142816uaa.2 for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3kF7HqY/S5zy7mX19L95ZlEeL6aqtjf7yLAuWZVzlz0=; b=U5UssZr+Nsv7vDYfhtiDM2EHeIUh/jdzcEbSktnOrQ1TUT3sLcl4eLusanpgAl299L g/f5mJNUu3BWBgb1LNc4JwcqRfskKW+wbRVmYPAsHWxAomPvmfo9iE4p5tUhz2BewLR9 VfG4g8pos2c33cMEovFNBY2cL+OR1JEjbEa6cTpXHg9gaeBMXv52SYOquSO55BzX4r35 NquyFO8rqQa3RHB1HTBYtNMrW3BtwieaD5BEfuvXyQUqLBtkAgQ7WRjGkQ7vU2zgam9C ipc3/QbPgySq7qK4YoYvlyf1bGS2S2GKJ3LCTdR+Kuc6NyVv2KKMuL/KzvtiURd32hz2 Ar/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3kF7HqY/S5zy7mX19L95ZlEeL6aqtjf7yLAuWZVzlz0=; b=Sdr0gQMxp4LCxyHwTyi99gbZI0tobx9zWxvrTp1frzArqw0tkdn5SSCLRM1kgqERXK Zs85ExUQzXcstAYKiDwTWVpz8wBGadISea92/04D9CAbm0UZ3w6puLvV3YsCULx42Xd0 ttd75SiOVWElK8ZS7mguTNtNDvEYffh9rbwy1FUROLCTYC4CaVpr2GRMKOaL623NIzgN q+LbHSeLkB9oVs1y9GYO9JxvohiDsZgss/o9K30ngkuWOK7M+jxih+72Soa9IJvcH6Y1 QT4sI1dz411gzMLGFWVP7bzZX47FQrlBOF7/BOlNuEeHP3YRAb27keA3EhKrL/LlzYug bCQA== X-Gm-Message-State: AKS2vOxaUGAjKb+vtg3FqGqy6UHPRZEsBkjiJkTlN6shZ0A1b1KAI5Uh nBjkYcYmxC4wTF9+/u+WFwcUu6bQUNtH5Hc= X-Received: by 10.159.59.94 with SMTP id j30mr4071178uah.72.1497410941466; Tue, 13 Jun 2017 20:29:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 20:29:00 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 20:29:00 -0700 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403043ed9e83fbee10551e3279a" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:29:04 -0000 --f403043ed9e83fbee10551e3279a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton > 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 wit= h >> 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=E2=80=8B isn't closely coupl= ed 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. > As Pete Resnick loves to point out, RFC prose can be normative without using RFC2119 words. The text of RFC2119 counsels against unnecessary use of the words it defines. It also contains this language: "...actually required for interoperation" (which use of rsa-sha1 clearly does not impede) "or to limit behavior which has potential for causing harm". I suppose this latter is the key issue. Still, I don't find it necessary or appropriate with respect to deprecating rsa-sha1, for reasons previously given. -MSK --f403043ed9e83fbee10551e3279a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Tue, Jun 13, 2017 at 6:55 PM, Jim = Fenton <fenton@bluepopcorn.net> wrote:

<= div bgcolor=3D"#FFFFFF">=
That being the case, why do we think people will pay attention to a MUST NOT today?
=20

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.=C2=A0 Scott claimed nobody pays att= ention to the advice in RFCs ("Operational practice=E2=80=8B isn't= closely coupled with standards changes").=C2=A0 If that's true, t= hen there's no meat to a MUST NOT anyway, and it really only matters wh= at people will implement.=C2=A0 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.

As Pete = Resnick loves to point out, RFC prose can be normative without using RFC211= 9 words.

The text of RFC2119 counsels against unnecessary use of the= words it defines.=C2=A0 It also contains this language: "...actually = required for interoperation" (which use of rsa-sha1 clearly does not i= mpede) "or to limit behavior which has potential for causing harm"= ;.=C2=A0 I suppose this latter is the key issue.

Still, I= don't find it necessary or appropriate with respect to deprecating rsa= -sha1, for reasons previously given.

-MSK
= --f403043ed9e83fbee10551e3279a--