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 891B91287A0 for ; Mon, 12 Jun 2017 09:52:23 -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 Y_7PHKRQbE-w for ; Mon, 12 Jun 2017 09:52:21 -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 E6819127866 for ; Mon, 12 Jun 2017 09:52:21 -0700 (PDT) Received: from splunge.local ([IPv6:2601:205:8302:79b1:f94e:a05d:edb7:58d1]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5CGqIr2000720 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 12 Jun 2017 09:52:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497286340; bh=Nbgr+1qBGv+ANAUktjnin7dFIwvLBbnd1+6n4/65jMw=; h=Subject:To:References:From:Date:In-Reply-To; b=tvFaAaA6vLXy3CqClndAhav3yUXYyQO8dfOCbHa80x5BsukLRksQGsP4VkyO5gS2D GTyFNakwaP+PE1aEJ6e9svXeKRE+4VtqX/eoGym3mqU0IEU9V3iYxRODXwtmVemhHs fXs8XnN2OJNGrXL8ZPTPjCJBt54ms9uP4EB9SuMY= To: dcrup@ietf.org References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> From: Jim Fenton Message-ID: Date: Mon, 12 Jun 2017 09:52:13 -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: Content-Type: multipart/alternative; boundary="------------E9E8940C8E0F5E3573A4D7A3" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt 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: Mon, 12 Jun 2017 16:52:23 -0000 This is a multi-part message in MIME format. --------------E9E8940C8E0F5E3573A4D7A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/11/17 8:28 PM, Murray S. Kucherawy wrote: > On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson > > wrote: > > I find the construction of this draft strange. Why not simply say > "verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"? > The remainder of the text is largely unchanged, which took me a whi= le > to validate. > > The problem here is that removing the definition of rsa-sha1 is not= > the point. The code point can't be undefined (Section 7 gets that > right), and we don't really benefit from having the definition > removed. What we want is to have rsa-sha256 implemented and deploy= ed. > > So say two things, just to be perfectly clear: > > 1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted. > > 2. DKIM implementations MUST use rsa-sha256. Signers MUST create > signatures using rsa-sha256 and verifiers MUST verify those > signatures. > > > That idea is fine with me. Specifically, I think "MUST NOT rely on" > is better than "MUST NOT implement". The difference between "rely on" and "implement" is not at all clear to m= e. Backing up: For interoperability, ideally we would have some transition time between when rsa-sha1 is no longer an acceptable signing algorithm and when it's no longer an acceptable verification algorithm. RFC 6376 didn't quite close the door on use of rsa-sha1 for signing, so it's premature to say that it's no longer acceptable for verification. Put another way, if a frequent correspondent of a domain signs with rsa-sha1, they're going to want to verify those signatures regardless of what we say here. Yes, rsa-sha1 is busted, but is it busted in a way that is likely to be exploited in this application? There are other weaknesses, most notably spoofing of key records in DNS, that are far more likely to be used; remember that DKIM tries to discourage other uses for keys (e.g., for data encryption) for those reasons. Also, factoring of keys and spoofing of key records are much more scalable than an attack on a particular message's hash. Does anyone have any data on how prevalent use of rsa-sha1 is currently in the field? If nobody is actually using it, I would believe that RFC 6376 closed the door more than I thought. -Jim --------------E9E8940C8E0F5E3573A4D7A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/11/17 8:28 PM, Murray S. Kucherawy wrote:
On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I find the construction of this draft strange.  Why not simply say
"verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"?
The remainder of the text is largely unchanged, which took me a while
to validate.

The problem here is that removing the definition of rsa-sha1 is not
the point.  The code point can't be undefined (Section 7 gets that
right), and we don't really benefit from having the definition
removed.  What we want is to have rsa-sha256 implemented and deployed.

So say two things, just to be perfectly clear:

1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted.

2. DKIM implementations MUST use rsa-sha256.  Signers MUST create
signatures using rsa-sha256 and verifiers MUST verify those
signatures.

That idea is fine with me.  Specifically, I think "MUST NOT rely on" is better than "MUST NOT implement".

The difference between "rely on" and "implement" is not at all clear to me.

Backing up: For interoperability, ideally we would have some transition time between when rsa-sha1 is no longer an acceptable signing algorithm and when it's no longer an acceptable verification algorithm. RFC 6376 didn't quite close the door on use of rsa-sha1 for signing, so it's premature to say that it's no longer acceptable for verification. Put another way, if a frequent correspondent of a domain signs with rsa-sha1, they're going to want to verify those signatures regardless of what we say here.

Yes, rsa-sha1 is busted, but is it busted in a way that is likely to be exploited in this application? There are other weaknesses, most notably spoofing of key records in DNS, that are far more likely to be used; remember that DKIM tries to discourage other uses for keys (e.g., for data encryption) for those reasons. Also, factoring of keys and spoofing of key records are much more scalable than an attack on a particular message's hash.

Does anyone have any data on how prevalent use of rsa-sha1 is currently in the field? If nobody is actually using it, I would believe that RFC 6376 closed the door more than I thought.

-Jim
--------------E9E8940C8E0F5E3573A4D7A3--