Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds

Scott Kitterman <sklist@kitterman.com> Sat, 10 June 2017 20:29 UTC

Return-Path: <sklist@kitterman.com>
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 31629128D69 for <dcrup@ietfa.amsl.com>; Sat, 10 Jun 2017 13:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=kitterman.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 EuNEsRNmXpu2 for <dcrup@ietfa.amsl.com>; Sat, 10 Jun 2017 13:29:24 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA958126D85 for <dcrup@ietf.org>; Sat, 10 Jun 2017 13:29:24 -0700 (PDT)
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A7518C40218 for <dcrup@ietf.org>; Sat, 10 Jun 2017 15:29:23 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497126563; bh=KPkOdvtIlC3mWr5EqQXX774+g1p0/VR7yOd/zLzeU7I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sre4VWSVbx24M2FrkB/2eeRx5lu76xEylkYy2MJF2N4w09uc9GqSe4u80Wt1+C7ga Mf/J760ksPvEMyXuWW/uqfNZPA7onXTf0WfXjzFH56TdLjHD02kGkaqZGcG8dxJEVm pIV8YlwvWZboViakbf8bdwA7pe1R578rbZyjyClw=
From: Scott Kitterman <sklist@kitterman.com>
To: "dcrup@ietf.org" <dcrup@ietf.org>
Date: Sat, 10 Jun 2017 16:29:23 -0400
Message-ID: <44047203.rS5CgVd1do@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <c38cbdf473a54a649a5acf4228909741@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <3226783.Zmkt5g0zON@kitterma-e6430> <c38cbdf473a54a649a5acf4228909741@usma1ex-dag1mb1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/n2xKTkCg02-rNLCYpuRcsn1tN9I>
Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds
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: Sat, 10 Jun 2017 20:29:26 -0000

On Saturday, June 10, 2017 08:02:46 PM Salz, Rich wrote:
> > Given that (which I wasn't aware of), I'll revise my estimate downwards. 
> > I
> > still think a separate draft for clearing out the obsolete cruft is worth
> > advancing and getting done.
> 
> Yes, there's a growing tradition for "die-die-die" documents.

OK.  Given that, I'd like to resolve the question of how to refer to rsa-sha1 
in section three.  There, as far as I can tell, two visions, roughly what's in 
-02 and what was in -01:

Current (-02):

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    Generally, DKIM supports multiple digital signature algorithms.  One
>    algorithm, rsa-sha256, is currenlty defined.  Signers MUST implement
>    and sign using rsa-sha256.  Verifiers MUST implement rsa-sha256.
> 
> 3.1.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.2.  Key Sizes
...

and -01:

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    DKIM supports multiple digital signature algorithms.  Two algorithms
>    were defined by [RFC6376]: rsa-sha1 and rsa-sha256.  Signers MUST
>    implement and sign using rsa-sha256.  Verifiers MUST implement rsa-
>    sha256.  The rsa-sha1 signing algorithm is obsolete and MUST NOT be
>    used.
> 
> 3.1.  The rsa-sha1 Signing Algorithm
> 
>    This algorithm is obsolete and MUST NOT be used.
> 
> 3.2.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.3.  Key Sizes
...

Personally, I prefer the explicit MUST NOT we had in -01 and I think that's 
along the lines of what Martin Thomson was suggesting.  A hatless msk 
preferred something more like what's there now.

Technically, I think the amount to the same thing.  Is it better to be more 
explicit about what's being removed or be implicit by removing it from what's 
specified?  Personally, I think explicit is better than implicit, but being a 
Python guy, I would [1]

Scott K

[1] https://www.python.org/dev/peps/pep-0020/