Just ones where there's something to say,
Cheers,
Stephen.
Eric Allman wrote:
#1 saying "proof" and "non-repudiation" in the abstract is a
mistake and potentially misleading. Rephase to use less difficult
terms, e.g. talk about signatures being evidence rather than proof.
Given the sensitivity over the exact wording of the abstract, I'm not
willing to make this change without discussion of some proposed wording.
Ok, I'll back off on this. DKIM isn't the only document that includes
such phrases (but if you could even just not say "non-repudiation"
that'd be great).
#2 1.1, 1st set of bullets. The biggest difference between dkim and
s/mime or pgp signatures IMO is that with dkim we do not expect
that signature failure will lead to message (delivery) failure,
whereas with s/mime or pgp we do. I'd mention this in a bullet.
There seems to be a difference of opinion on this, so I'll leave it for
now.
Ok.
#3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS.
Better to say that dkim requires no *new* ttp.
I don't see DNS as a "third party" in the same sense as a CA for certs.
Yes, DNS has to work, but it isn't a third party (unless you want to
count the root servers, I suppose). By this logic, we should also
include the multiple third parties that run the routers and all the rest
of the infrastructure.
In my little PKI-riddled mind, the DNS is a TTP since it supplies the
public keys and if/when DNSSEC were used, it starts to look quite like
a PKI. The routers etc. won't ever really be supplying signed key
records. But if no-one else thinks the same, leaving as-is if of course
right.
#5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest
changing from: "That hash is then signed by the signer using the
RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]; in
particular see section 5.2) with an exponent of 65537 as the
crypt-alg and the signer's private key. The hash MUST NOT be
truncated or converted into any form other than the native binary
form before being signed." ...to... "The signature is calculated
using the RSA algorithm with a fixed public exponent of 65537 - if
a different public exponent is required, then a new DKIM signing
algorithm must be defined."
Adding the specific reference was specifically requested by another
reviewer --- in fact, I think your proposal changes it back to almost
exactly what was objected to before. I think this requires some
discussion.
Sorry - you're right about the reference, I just forgot to include
it, you could change text suggestion to: "The signature is calculated
using the RSA signature algorithm as specified in PKCS#1 version 1.5
[RFC3447], and with a fixed public exponent of 65537 - if a different
public exponent is required, then a new DKIM signing algorithm tag
value must be defined."
#7 3.3.4 says "RSA keys of at least 1024 bits" and similar. The 1024
refers to the modulus length so that would be more correctly stated
as "RSA keys with modulus at leat 1024 bits long". Similar fixes
could be done with other parts of the same section.
I would like some discussion on this. This might be more technically
accurate for a cryto expert, but I know that if I as a non-crypto guy
read this, I would immediately ask myself "now, is that the same as the
key length or something else altogether?"
Fair point. I was probably being a bit pernickity.
#13 3.4.5, 2nd informative note: I think this just repeats stuff in
the 1st informative note and could be deleted.
The point of this note was to provide a clear rationale, which doesn't
really seem to be fully done in the first (implementation) note. I
moved it up before the first note and deleted the first sentence of the
implementation note, so it now reads:
INFORMATIVE RATIONALE: This capability is provided because it
is very common for mailing lists to add trailers to messages
(e.g., instructions how to get off the list). Until those
messages are also signed, the body length count is a useful
tool for the verifier since it may as a matter of policy
accept messages having valid signatures with extraneous data.
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits
enables an attack in which an attacker modifies a message to
include content that solely benefits the attacker. It is
possible for the appended content to completely replace the
original content in the end recipient's eyes and to defeat
duplicate message detection algorithms. To avoid this attack,
signers should be wary of using this tag, and verifiers might
wish to ignore the tag or remove text that appears after the
specified content length, perhaps based on other criteria.
Does this address your comment adequately?
Ok.
#19, 3.7. This talks about two hashes all the time, which is
correct, but a bit misleading since any sensible API will include
both hashing and private key application inside a "sign()"
function. The end result is that the dkim programmer calls "hash()"
once and either "sign()" or "verify()" once. Suggest adding a
sentence along these lines to clear that up. If someone ever
calculated "sign(hash())" then they'd be wrong and this text sort of
suggests that. Similar comment about the pseudo-code at the end
where I'd rather see something like:
body-hash = hash( canon_body )
signature = sign( canon_header || DKIM-SIG )
I disagree. This section has nothing to do with what an API would look
like, it's about what algorithms have to be applied and when. For
example, I can easily see your change being interpreted to mean that you
don't hash the header at all.
Fair enough. Its hard to get right either way. But can we add an
informative note somewhere like:
INFORMATIVE NOTE: Many digital signature APIs provide both hashing
and application of the RSA private key using a single "sign()"
primitive. When using such an API the DKIM signature calculation
pseudo-code might look more like:
body-hash = hash( canon_body )
signature = sign( canon_header || DKIM-SIG )
Were an implementer to mistakenly include a second "hash()" call,
i.e.,
signature = sign( hash (canon_header || DKIM-SIG ) )
they would sign and verify their own messages with no apparent
problems, but could not interoperate with correct implementations.
#22, 5.2, last para. Change "when the selector containing the
corresponding public key is expected to be removed before the
verifier...", to, "when the public key in the relevant selector is
expected to be revoked before the verifier..." since we're not
recommending removing the selector but rather zeroing out the key.
Is that what we are recommending? I thought that omitting the key was a
way of saying "we're sorry, but we had to pull that key unexpectedly."
In fact, the usual way of dropping a key would be to drop the record
entirely. Otherwise you would have ever-growing name spaces.
I guess I'm confused then. I thought that including a blank key
value was better since it could be cached. I would assume that
you then typically delete the selector record after a while, when
you no longer see many requests for it or whatever.
#28, 6.2. The reference to ID-AUTH-RES might be better off being
removed for process reasons.
Even as an example? It's informational, not normative.
I appreciate that, but I bet it'd still slow down base's road
to rfc-dom.
#32, A.3, the authentication results header should not, IMO be
included here.
I think it is very important to make it clear how one might convey
results to higher levels. Otherwise all of A.3 doesn't have any
reasonable example. It doesn't have to be Authentication-Results, just
something.
An abstract something here is better than a nearly-well-defined
something IMO. (I mean no criticism of ID-AUTH-RES here either, but
it may change in all sorts of ways, including the name of the header
field.)
#33, Appendix B. I expected to see a bit here about the type of
setup we have at IETF meetings, where the IETF's MTA signs and the
verifier has to handle the From being nothing like the signer
identity.
Sorry, I don't see any signatures coming from the IETF MTA. Can you be
more specific?
If I go to a conference or IETF, then I generally use its smtp server.
If someone was used to mail from me being signed by tcd.ie and suddenly
see mail from me signed by ietf66.org they might react badly. I don't
want that to happen. (I know that the IETF meeting server doesn't sign
now, but I guess it may in future.)
So, my point was that I didn't see an example/use-case that mapped to
the one above.
#34, Appendix C. I think that this can be deleted. Others may
disagree. In any case, the text says 768 and the command line 1024,
no password handling is shown and the last part could confuse since
that signature is not usable for DKIM. So if this isn't deleted,
then a bunch of changes are needed.
I fixed the discrepancy, but I don't think it should be deleted. It's
non-normative and will help people understand how to use the standard,
which I think is A Good Thing.
I'm not sure what you mean about password handling. I just ran through
these instructions, and there are no passwords requested.
Sure, you don't have to use passwords with s/w private keys, but you
really should do at least that much.
If we're going to give this kind of help, we don't want it to encourage
people to take less secure options without being clear that that's what
they're doing.
#5 3.5, last para before tags says: "Defined tags are described
below." which is sort of obvious. Suggest deleting it.
Done (but why do I have the creepy feeling someone is going to object?).
I object!
#6 3.6.1 "k=" says that the public key is in the "p=" value, but its
actually the modulus.
I guess I'm confused. If this isn't the public key, what is?
Me being pedantic again I guess. The public key is the modulus and
the public exponent (in our case hardcoded to be 65537).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html