Re: Last Call: <draft-ietf-dcrup-dkim-crypto-09.txt> (A new cryptographic signature method for DKIM) to Proposed Standard

"John Levine" <johnl@taugh.com> Wed, 30 May 2018 20:59 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD612D873 for <ietf@ietfa.amsl.com>; Wed, 30 May 2018 13:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.753
X-Spam-Level:
X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bDuQoa6h; dkim=pass (1536-bit key) header.d=taugh.com header.b=HSSTNJmm
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 AzobiMbujZue for <ietf@ietfa.amsl.com>; Wed, 30 May 2018 13:59:17 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F029412895E for <ietf@ietf.org>; Wed, 30 May 2018 13:59:16 -0700 (PDT)
Received: (qmail 10239 invoked from network); 30 May 2018 20:59:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=27fd.5b0f10a3.k1805; bh=I+18RtF+/E6c2zNsJ18OhOgJN/hv9kfdYP8dbml0738=; b=bDuQoa6hodJzMoWXM/tOy+4HgxU2fyeCoT/hoQf8vJWF0QBSdIpI/QVic8xcZcECllk0539dWFQCVLqFE+FHRJEvmnCFb4jAxnSWDn3IdljQugeXgakYcgoGSDDV2adOO0ojjLSQli6Gnk6LYzngEkGSJ1Scw54/1vxW5fn2vIMpr+bEb9c8hQPbJ3Yu92eRyZEFVN+QKMUFV+jww8uezLrrUz0bBeGSAlPl7lL1elW6/rS0bspHqTCJGLXJfJE8
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=27fd.5b0f10a3.k1805; bh=I+18RtF+/E6c2zNsJ18OhOgJN/hv9kfdYP8dbml0738=; b=HSSTNJmmh0LIxGrzokCCxMWvMjoc3PYeKS+OGW+Ty5kWbetLVts2MLBfOrrQg4/S0qgkEQoQtFBT1phXCyM/Lffa6c8yI1iUyIzWFC7CQhIQLjjdcEied6R9Pp1y+qljGgonAnygGAJ+fYHNVjlgq6c2t5PldGuuCHaFnRxEsH8P+3M5qnZISowvdwncUdriqDiRN0rji1MbmXsG2/KB5cEZMs+rhrRzsp1S7MalDW4ErPEHKQWZhnnp993zhUqV
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 May 2018 20:59:15 -0000
Received: by ary.qy (Postfix, from userid 501) id 4FA192763AD3; Wed, 30 May 2018 16:59:14 -0400 (EDT)
Date: Wed, 30 May 2018 16:59:14 -0400
Message-Id: <20180530205915.4FA192763AD3@ary.qy>
From: John Levine <johnl@taugh.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-dcrup-dkim-crypto-09.txt> (A new cryptographic signature method for DKIM) to Proposed Standard
In-Reply-To: <D4920629-1B2C-4123-A2FC-209A4986C8C4@vigilsec.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/keVSTsS5njwrlzfrOHnZ5yUUJV0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 May 2018 20:59:19 -0000

In article <D4920629-1B2C-4123-A2FC-209A4986C8C4@vigilsec.com> you write:
>I have three comments on draft-ietf-dcrup-dkim-crypto-09.
>
>In section 3, this document says that it uses "PureEDdSA"; however, RFC 8032 provide a definition for PureEdDSA.  I
>assume this is a simple typo.

yEs

>How hard would it be to expand section 6 to include an example of two selectors being used, one with RSA and one with
>ed25519?  If it is pretty easy, I think it would help the reader.

I can ask the guy who produced the example.  It shouldn't be very hard.

>RFC 6376 have an extensive security considerations section.  This document should point out that the private key
>protection discussed in Section 8.3 of RFC 6376 applies to the ed25519 private key.  In addition, I think there should
>be a section similar to Section 8.13 of RFC 6376 in this document; it might just be a pointer to Section 8 of RFC 8032.

I don't disagree with any of the points but it all seems so obvious
other than perhaps the pointer to the 8032 security section.  I'm
trying to envision the person who has sufficient skill to add EC keys
to his DKIM setup but has to be reminded that it would still be a bad
idea to publish the public keys.

Perhaps I can add a sentence saying that all of the security advice in
6376 applies except that the advice in 8032 supercedes the
RSA-specific advice.

R's,
John