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 7908213162C for ; Tue, 20 Jun 2017 13:11:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lsxyZG2u17rm for ; Tue, 20 Jun 2017 13:11:40 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 7C2D2131561 for ; Tue, 20 Jun 2017 13:11:38 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id y47so75768020oty.0 for ; Tue, 20 Jun 2017 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uHQyHWK9mZptnq63jdz1+W+GjTSi0C74+NRmWZT6Hqw=; b=OVWExejeu6e2EhQ34oxNeNCN3U75mdPVE1Qh/6re+sE6ndjwH++a8wBevmVV8A8+av RTBbAFxBp+PaqGZ8A70+8a5VxL5JWqoKM4+ZzR2lR3Rer+JzZxhrmOLjHDBF80leuuaA MXMLvF2QGqPX7MsYYHFf557vrcBpefIZnPloFaMKuALq+e1O82K+5zMEJqXzTx1XhPq0 ZItIxeJo649roTL5MbaTMOdrudx7uS+pVdplnqzHJjXYiLY6Y2n8Bso+y8GbLx7AemwA /2GXcgpgzfKIfeO3BDjw467EW/3+9W84P2d9Jj7zh0ePJ5vruH8tcozf/FdnZrxS1SxV mZyQ== 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; bh=uHQyHWK9mZptnq63jdz1+W+GjTSi0C74+NRmWZT6Hqw=; b=uNhWgoquRGZgmRSVbGRNnntKzDv6hWGjnkW3DuZ7JsP1oyg4zHhUMipNZTEJw44Gt6 h1Nx4fGH04HmzPanMjJDvcJkmmrqfDHXx4jU/6n3yFCxsyiMrh5PtCSD9EKLwQBuLNK0 CUIVV2cDMoe8kFR/YHrNoOGvjggU+8hZSmAhobajHAcjD9zr1lEnkU475KF3x9+dFMVz yLCVk/D+EY7nQH52lLUiBon2Xr56Kr1h6Yaed+nfglDjF0IRyqEyv1aG+DeGq8u+n8Go rDug/lFswFHXgMnOhoj8l/X6XLSQEhEQNEuBwCbZLwJzZR1F4NdkXl9UFxZi4fOoSmKk 2enw== X-Gm-Message-State: AKS2vOw4v6YtHToMs/TwgS49efr61DBlqjV7IN8L6Svp+idKzPa3GNLh TkOwmpTlT0cGnYF03VYtx7ZMP2gJxTTjlj4= X-Received: by 10.157.40.238 with SMTP id s101mr20194129ota.88.1497989497564; Tue, 20 Jun 2017 13:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Tue, 20 Jun 2017 13:11:37 -0700 (PDT) In-Reply-To: References: <1642300.47WuTbIWPP@kitterma-e6430> From: Brandon Long Date: Tue, 20 Jun 2017 13:11:37 -0700 Message-ID: To: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a113edb94e1a603055269db10" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals 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: Tue, 20 Jun 2017 20:11:42 -0000 --001a113edb94e1a603055269db10 Content-Type: text/plain; charset="UTF-8" I think we should go for removal. I don't think implementation wise for receivers who have a choice, that removal vs deprecation is going to have a big short-term impact, I doubt most receivers would remove rsa-sha1 at the publish date or on the deprecation date in the registry. They'll assess the damage between keeping it or removing it based on the current timeframes. The larger question will be if implementations that others depend on start removing it, ie if you upgrade your version of opendkim and rsa-sha1 is no longer supported, you'll likely have unexpected changes to your receiving. That said, I think that deprecation doesn't change the status quo enough. Brandon On Tue, Jun 20, 2017 at 12:00 PM, Kurt Andersen wrote: > > > On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman > wrote: > >> >> I think there are roughly three options that have been discussed: >> >> Status quo: >> >> > Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST >> > implement both rsa-sha1 and rsa-sha256. >> >> Deprecate rsa-sha1: >> >> > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> > implement both rsa-sha1 and rsa-sha256. >> >> Remove rsa-sha1: >> >> > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> > implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. >> Note: This option also removes rsa-sha1 from the ABNF. >> > > [elided] > > Remove rsa-sha1: >> This option eliminates (to the extent it is adopted) the potential of >> security >> risks with rsa-sha1. . . >> While this might be considered somewhat abrupt, rsa-sha1 signing has been >> effectively SHOULD NOT for a decade. Maybe this will create some >> momentum for >> operators to move off of it. >> >> It is abrupt to remove something without a formal deprecation period. >> > > I'm in favor of moving strongly and clearly to kill sha1, but what about > moving it out to the registry with a dated "MUST NOT". That provides for a > deprecation period without the need for further intervention. The other > advantage is that it provides a stronger historical record that people can > point to when explaining brain-deadness to people who have not updated :-) > I would suggest a "drop dead" date of something like mid-2018 to allow the > rest of this work to reach completion. > > --Kurt > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a113edb94e1a603055269db10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we should go for removal.

I don= 't think implementation wise for receivers who have a choice, that remo= val vs deprecation is going to have a big short-term impact, I doubt most r= eceivers would remove rsa-sha1 at the publish date or on the deprecation da= te in the registry.=C2=A0 They'll assess the damage between keeping it = or removing it based on the current timeframes.

Th= e larger question will be if implementations that others depend on start re= moving it, ie if you upgrade your version of opendkim and rsa-sha1 is no lo= nger supported, you'll likely have unexpected changes to your receiving= .=C2=A0 That said, I think that deprecation doesn't change the status q= uo enough.

Brandon

On Tue, Jun 20, 2017 at 12:00 PM, Kur= t Andersen <kurta@drkurt.com> wrote:


On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitte= rman <sklist@kitterman.com> wrote:

I think there are roughly three options that have been discussed:

Status quo:

> Signers MUST implement and SHOULD sign using rsa-sha256.=C2=A0 Verifie= rs MUST
> implement both rsa-sha1 and rsa-sha256.

Deprecate rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement both rsa-sha1 and rsa-sha256.

Remove rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement rsa-sha256.=C2=A0 rsa-sha1 is obsolete and MUST not be used.=
Note: This option also removes rsa-sha1 from the ABNF.

[elided]=C2=A0

Remove rsa-sha1:
This option eliminates (to the extent it is adopted) the potential of secur= ity
 risks with rsa-sha1. =C2=A0. =C2=A0.
While this might be considered somewhat abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade.=C2=A0 Maybe this will create some mome= ntum for
operators to move off of it.

It is abrupt to remove something without a formal deprecation period.

I'm in favor of moving strongly a= nd clearly to kill sha1, but what about moving it out to the registry with = a dated "MUST NOT". That provides for a deprecation period withou= t the need for further intervention. The other advantage is that it provide= s a stronger historical record that people can point to when explaining bra= in-deadness to people who have not updated :-)
I would suggest a = "drop dead" date of something like mid-2018 to allow the rest of = this work to reach completion.

--Kurt

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a113edb94e1a603055269db10--