Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds

[Scott Kitterman <[e-mail]>]

On Monday, June 12, 2017 12:23:16 AM Murray S. Kucherawy wrote:
> On Sun, Jun 11, 2017 at 9:38 PM, Scott Kitterman <[e-mail]>
> 
> wrote:
> > The IETF is five years late with action on this front.  At least.
> > Whatever is
> > happening in this working group, hurrying isn't on the list.
> 
> Then I don't understand why this thread seems to be so tense with
> frustration.

I think getting rid of sha1 and keys < 1024 bits should be really easy.  

I THOUGHT we had all agreed to get that done and out of the way.  In the space 
of two days we went from "OK, almost done" to "Here's three different visions 
for how the draft should be written that all say the same thing" or maybe 
don't bother.  That's frustrating.

I find the notion that it's not an interoperability problem for signers to 
sign with keys that receivers will ignore frustrating.

> > I have no idea what should be in this draft or if it should even exist
> > anymore.
> 
> I really don't think the proposed changes are all that major here.

If I knew which of the three approaches to take, then I could  pick one and 
write it:

1.  Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MUST NOT 
rsa-sha1 (my personal preference)

2.  Fully replace section 3.3 dropping rsa-sha1 and just giving the new 
requirements (possibly with an appendix that says MUST NOT rsa-sha1)

3.  Make the draft a lot shorter and only state updated requirements.  Also 
don't remove rsa-sha1 [1]

As a maintainer of an implementation of RFC 4871 and its updates (e.g. RFC 
6376) and its updates, I strongly prefer option #1.  That structure makes it 
very easy to see what needs changing when I update the code.  

Using the approach in option 2 I need to either mentally diff RFC 6376 and the 
new document (or if we add it look at the main body of the text and an 
appendix) to determine what to do.  It's less clear.

Option 3 makes the entire document a no-op.  It both fails to remove rsa-sha1 
and offers no guidance on key sizes.  The one new thing it says (compared to 
RFC 6376 is "Verifiers MUST NOT rely on the rsa-sha1 algorithm".  What does 
that even mean?  Since rsa-sha1 is not removed from the ABNF, it's still a 
required part of the protocol.  Once we add an ECC algorithm are all three 
going to be required?

I would like to know what the group prefers.  I'll do whatever, but I really 
have no idea what that is.  If option 4 is kill the document, my ranking would 
be:

1
2
4
3

> > I also really don't understand why we have a discussion about if a draft
> > should be adopted before a WG adopts it if we just get to re-have the same
> > discussion periodically.
> 
> You think working groups should not be allowed to revisit their choices?

You think working groups should have a bi-weekly periodic on revisiting 
choices?  Of course choices can be revisited, but if decisions aren't at all 
sticky, then there's no way to make progress.

Scott K

[1] https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1/commits/b7815a3b876c5b57f7eff4537ed0c0e9eef497a8