Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt

[Scott Kitterman <[e-mail]>]

I hear you.  I expect this to be the most contentious part of the draft.

Here's my counter argument:

The first DKIM RFC (RFC 4871), published in 2007 said:

> Signers MUST implement and SHOULD sign using rsa-sha256

I believe that the only reason rsa-sha1 was included at all was to make 
transition from domainkeys easier (see RFC 4870).  That's also (as I 
understand it where the 512 bit minimum key size came from).

We've already had a decade for transition.  I think we are well into the 
territory that if there are signatures being done with rsa-sha1, it's unlikely 
to change until they stop working.

In related news, I added an informative reference to RFC 6194 and mentioned it 
in security considerations.

Fundamentally, I don't think anything other than removing it entirely changes 
anything.  As long as receivers MAY, they probably will and if they don't 
senders will complain "Why didn't you?", it's still allowed.  MUST NOT on both 
sides of the equation gives a clear answer.  "Go read RFC XXXX.  If it's a 
problem for you, you aren't doing something you SHOULD have been doing since 
2007, so you own the interoperability problem."

If someone doesn't want to drop rsa-sha1, they are free to not implement that 
change, so I don't see leaving the MAY in there for receivers as advantageous.

We know we need to add a new algorithm to replace it and two is plenty.  Let's 
kill it dead.

As a working group document editor, I'll change it however the group wants (of 
course), but I think we should either kill rsa-sha1 entirely in this document 
or leave it out entirely and let one of the follow-on documents add a new 
algorithm and remove rsa-sha1.  Preferably a clean kill or, failing that, not 
at all is what I think we should do.

Scott K

On Monday, June 05, 2017 12:21:08 PM Rose, Scott wrote:
> I’ve read the draft and I admire the willingness to plant a stake in
> the ground in making rsa-sha1 obsolete.
> 
> I think it would help to be more explicit about which requirement
> applies to which role (implement vs deploy/administrate).  For example:
> 
> 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 and MAY implement rsa-sha1 for backwards compatibility.
>     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 by signers.
> 
> 
> This doesn’t change the main idea, but calls out the fact that
> rsa-sha1 will be sticking around for a period of time as administrators
> are not going to read this doc and/or not going to change things that
> are working for them now.
> 
> Scott
> 
> On 30 May 2017, at 20:58, [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the DKIM Crypto Update of the IETF.
> > 
> >         Title           : Cryptographic Algorithm and Key Usage to
> > 
> > DKIM
> > 
> >         Author          : Scott Kitterman
> > 	
> > 	Filename        : draft-ietf-dcrup-dkim-usage-00.txt
> > 	Pages           : 5
> > 	Date            : 2017-05-30
> > 
> > Abstract:
> >    The cryptographic algorithm and key size requirements included when
> >    DKIM was designed in the last decade are functionally obsolete and
> > 
> > in
> > 
> >    need of immediate revision.  This document updates DKIM
> > 
> > requirements
> > 
> >    to those minimaly suitable for operation with currently specified
> >    algorithms.  This document updates RFC 6376.
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-00
> > 
> > 
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > _______________________________________________
> > Dcrup mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dcrup
> 
> ===================================
> Scott Rose
> NIST ITL
> [e-mail]
> [phone]
> GV: [phone]
> ===================================
> 
> _______________________________________________
> Dcrup mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dcrup