Re: [Dcrup] [taugh.com-standards] Benjamin Kaduk's No Objection on draft-ietf-dcrup-dkim-crypto-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Sat, Jun 16, 2018 at 03:01:09PM -0400, John R. Levine wrote:
> [Benjamin Kaduk wrote]
> > suggested changes, it's really unclear what conclusion to draw when
> > the review is met with a curtain of silence.
> 
> I already wrote back to Paul, didn't realize I needed to tell the entire 
> IETF.

I guess you don't really, though there are some benfits from leaving
at least secdir@ cc'd.
It would have been good to tell "the IETF" (in some form) that you
were talking more to Paul off-list, though -- that would probably
have saved us some electrons today.

> > % I believe the [FIPS-180-4-2015] reference should be replaced with a
> > % reference to RFC-6376
> >
> > Still relevant.  (This is the citation for SHA-256; we generally
> > prefer IETF references to external references.)
> 
> RFC 6376 is the DKIM spec that we are updating.  It uses SHA-256 and 
> defines it by referring to the FIPS document.  I suppose I could change it 
> to "see RFC6376 reference FIPS-180-3-2008" but that seems cruel, and would 
> miss the fact that 180-3 has been updated since 6376 was published.

Okay, shame on me for not looking closely enough and making
assumptions.  It looks like RFC 4634 is the "US Secure Hash
Algorithms" one I was thinking of (which is even older, referencing
180-2).  I don't know whether this work relies on any of the
differences in the FIPS standards between those versions, and won't
ask you to chase it down, either, but I will express slight surprise
that RFC 6376 references FIPS directly for SHA256.

> > % Remove or indicate the RFC Editor should remove the following text:
> > %
> > %       Discussion Venue:    Discussion about this draft is directed to the
> > %       [e-mail] [1] mailing list.
> >
> > Still relevant.
> 
> Sorry, relevant to what?  Surely you're not saying that the staff in the 
> RPC don't know to remove this kind of stuff as they turn drafts into RFCs.

I have received explicit direction from the RFC Series Editor to
please point out early "things the RFC Editor ought to catch".
Everyone is human, and getting known issues fixed earlier on leaves
reviewers more free to spot other potential issues.  (And, as Jim
notes, it saves everyone time from having multiple reviewers point
it out.)

> > % This sentence doesn't parse easily:
> > %
> > %      This is an additional DKIM signature algorithm added to Section 3.3
> > %    of [RFC6376] as envisioned in Section 3.3.4 of [RFC6376].
> > %
> > % It should simply say something like "This document adds an
> > % additional key algorithm type to the DKIM Key Type Registry and a
> > % new signature type to the DKIM Hash Algorithms Registry"
> >
> > Still relevant, though AFAICT only the Key Type Registry is
> > impacted.
> 
> Having rewritten that sentence several times to get WG consensus, I am not 
> inclined to mess with it unless it is wrong, which I am reasonbly sure it 
> is not.

Okay.

> > % Section 4 and 8 have an introductory lines that says "update as
> > % follows" followed by a dot instead of a colon. That is a little
> > % confusing to the reader, as if some text is missing before the dot.
> >
> > Still relevant (though I guess I would prefer "as described in the
> > following sections" to using a colon).
> 
> Copyediting nit, the RPC will make it match whatever the style is.

I guess so, but see above.

> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> PS: if I sound crabby, my defense is that today is Porchfest in my village 
> and I've been hearing to my neighbors play bad folk music for the past 
> three hours.

That's a solid defense; I wish I had one as good for my own crabbiness.

Thanks for all the clarifications.

-Benjamin