Subject: [Dcrup] Benjamin Kaduk's No Objection on draft-ietf-dcrup-dkim-crypto-13: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Jun 2018 07:43:59 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dcrup-dkim-crypto-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the quick update letting me resolve my DISCUSS!

Thanks for writing this document; it will be good to have ed25519 available for DKIM.

There were some remarks in the secdir review that I don't remember seeing a response
to yet (though I'm not sure about the "DKIM Hash Algorithms Registry" part) -- it would be
good to see a reply to them as well as the updates already made.

---

From: "John R. Levine" <[email-masked]>
Date: 16 Jun 2018 10:56:39 -0400

> good to see a reply to them as well as the updates already made.

That was about a typo in an earlier version, fixed a while ago.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Jun 2018 13:27:50 -0500

> That was about a typo in an earlier version, fixed a while ago.

My ballot remark should be interpreted as "I think there are some
good comments in the secdir review, but I do not understand the part
of the secdir review that talks about the DKIM Hash Algorithms
Registry."  I don't know that an earlier rev of the document is
relevant, since the secdir review
(https://datatracker.ietf.org/doc/review-ietf-dcrup-dkim-crypto-12-secdir-lc-wouters-2018-06-11/)
claims to apply to revision 12, the same revision I initially
reviewed.

Since apparently this is difficult, let me go through the secdir
review item-by-item and comment on it:

% NITS:
% 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.)

% Remove or indicate the RFC Editor should remove the following text:
% 
%       Discussion Venue:    Discussion about this draft is directed to the
%       [email-masked] [1] mailing list.

Still relevant.

% 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.

% This text reads a little odd:
% 
%    Ed25519 is a widely used cryptographic technique, so the security of
%    DKIM signatures using new signing algorithms should be at least as
%    good as those using old algorithms.
% 
% It seems to suggest that being "widely used" is a guarantee for
% being "at least as good as older stuff". Better would be to just
% point to the Security Considerations of RFC 8032

Addressed in the -13.

% 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).

More generally, while it's oftentime just as fine to reply to a
directorate review with "thanks for your comments, but this text
will be clear for the document's target audience" as to take the
suggested changes, it's really unclear what conclusion to draw when
the review is met with a curtain of silence.

-Benjamin

---

From: "John R. Levine" <[email-masked]>
Date: 16 Jun 2018 15:01:09 -0400

> 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.

> %       [email-masked] [1] mailing list.

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.

> Still relevant, though AFAICT only the Key Type Registry is

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.

> following sections" to using a colon).

Copyediting nit, the RPC will make it match whatever the style is.

> 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.

Regards,

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.

---

From: Jim Fenton <[email-masked]>
Date: Sat, 16 Jun 2018 12:17:25 -0700

On 06/16/2018 12:01 PM, John R. Levine wrote:
> 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.

If there's any reason to spin another revision, I would suggest cleaning 
this up. I had initially thought that it was something the RFC Editor 
could fix as well, but it's not a good use of reviewers' time to make 
each of them point it out.

-Jim (as document shepherd)

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Jun 2018 14:28:43 -0500

On Sat, Jun 16, 2018 at 03:01:09PM -0400, John R. Levine wrote:
> [Benjamin Kaduk wrote]

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.

> 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.

> 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.)

> inclined to mess with it unless it is wrong, which I am reasonbly sure it 

Okay.

> Copyediting nit, the RPC will make it match whatever the style is.

I guess so, but see above.

> and I've been hearing to my neighbors play bad folk music for the past 

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

Thanks for all the clarifications.

-Benjamin

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 16 Jun 2018 17:57:40 -0500

Just among us chickens (and I'll be brief, because my crabbiness is due 
to a water leak that's requiring our floor to be torn out (as I type :-) ...

On 06/16/2018 02:28 PM, Benjamin Kaduk wrote:
> it out.
This may not match practice from previous IESGs, since the conversation 
Benjamin is referring to was a request from the RFC Editor that came in 
after he was named to the IESG last March. I remember the conversation 
and thinking "that must be something the RPC has to deal with fairly 
frequently, because they rarely ask the IESG for help with stuff like 
this".

So, this might be news to at least some parts of the community.

I might also mention that changing things like this early means the 
number of changes that authors are looking at during AUTH48 would be 
smaller, allowing authors to be "more free to spot other potential 
issues" as well. I don't know about other areas, but the list of changes 
in some TSV drafts can be impressive.

And now I'm off to watch our short dogs dog-paddle to keep their muzzles 
out of the water (I kid, a little :-)

Spencer