Subject: [Dcrup] Nits and bolts of draft-ietf-dcrup-dkim-crypto

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Sep 2017 13:20:15 +0200

Hi all,
some points in the document seem to be amendable.

*Introduction*

The first sentence is garbled:

   DKIM [RFC6376] signs e-mail messages, by creating hashes of the
   message headers and content and signing the header hash with a
   digital signature.

Traditional email literature, e.g. rfc5322, set header against body, and
envelope against content.  Above, content is mentioned but only the header hash
is surmised to be signed.  Usually, "signing with a digital signature" implies
the use of hashes without saying, doesn't it?  Perhaps that sentence wants to
say that DKIM carefully defines its own hashing algorithms?  I'd truncate the
first sentence at the comma.

In the last sentence, s/fits in a a 256/fits in a 256/.  Possibly, the
preceding "and a key fingerprint" could be "and a public key fingerprint", so
as to match the title of Section 3 literally.

*Public key fingerprints*

This section should also explain the obvious --but maybe not to all-- notion
that storing the hash of the public key does prove the ownership of a domain by
the same logic that storing the whole key does (albeit the latter may also
imply the availability of better tools).  Hence, the point of DKIM "to claim
some responsibility for a message by associating the domain with the message"
is fully attained by the new "fp" technique.

Why didn't p= have an url pointing to the key?  If the key is long, that would
seem to be convenient.  Personally, I view the requirement of enlarging each
message by the size of the key as a sort of punishment for not being able to
set up the DNS well enough.  If there is a better explanation, it might be
worth giving it.

In the last but one paragraph, s/it included in the signature/it is included in
the signature/.

*Signature syntax*

The p= public key is OPTIONAL, unless a=rsafp-sha256.  Formally, an rsafp
without public key does not verify, but is still syntactically correct.  A
different position needs a version bump, lest existing signatures without p=
become invalid.

The q= tag deserves being updated too.  While there are no formal changes, the
description given in rfc6376, "query methods used to retrieve the public key",
is no longer valid, as those methods are going to be used also to retrieve a
fingerprint.

*Transition Considerations*

The strategy outlined, to use different selectors, sounds correct.  However,
not all DMARC aggregate reports include the selector, perhaps because it is not
saved in Authentication-Results header fields.  If it is not bureaucratically
cumbersome to point out that issue, an audience of developers might find it
useful and improve their code.

*Duplicate Signature Key Selection*

The second sentence, 1st par., sounds incomplete:

   The primary motivation for this design is allowing for a smaller
   key representation of larger public keys.

Would the following (s/key/DNS/) be any better?

   The primary motivation for this design is allowing for a smaller
   DNS representation of larger public keys.

Regards
Ale