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

[Scott Kitterman <[e-mail]>]

On June 10, 2017 9:42:25 AM EDT, "John R. Levine" <[e-mail]> wrote:
>> If we don't get something that rips out the obsolete crypto soon,
>then 
>> ARC is either going to have to wait or have a separate crypto 
>> specification from DKIM.  I don't see a new protocol with rsa-sha1
>512 
>> bits getting approved.  Neither of those options is good.
>
>I'm not clear on what sequence you're expecting here.  Is this it?
>
>* Update DKIM to take out old crypto
>
>* Publish ARC with only sha256 and RSA1024.
>
>* Update DKIM to add new algorithm and maybe key hashes
>
>* What about ARC?
>
>I'm seeing at least four documents where we should only need two, one
>to 
>update DKIM, one to publish ARC with the same crypto.

Ideally, ARC will be able to use DKIM's crypto requirements by reference and not need its own separate definition.  If ARC can do that, then it doesn't need to be modified once this WG completes.

Today's DKIM crypto requirements are completely unsuitable and would (I hope) never get IETF consensus for a new protocol.  Getting from "unsuitable" to "suitable for today, but not future proofed" is easy.  That's what my draft does.  It's the minimal change needed to avoid ARC having to specify its own crypto requirements, which is what prompted, finally, this working group.

Eventually the working group lands another document that defines the post rsa-sha256 future as an update to DKIM.  Since ARC will incorporate the DKIM crypto requirements by reference, it won't need updating again.

So I see two documents from this WG:

 - one now to get DKIM crypto requirements to be minimally acceptable for today's use
- another to define requirements to be secure in the future so that someday, when it's no longer appropriate, rsa-sha256 can be replaced

Alternately, as you suggest, we land one document that does both.  I thought we made that decision when we adopted this document, so I don't know why we're having the conversation again now.  If we were going to land only one, then we don't need this document at all.

I think you are substantially underestimating the time it will take to get IETF consensus on a new approach based on ECC.  I think if it's done in a year, that'll be fast.

I think I'm done on this particular topic.  

Scott K