[ietf-dkim] editorials and nits

[Stephen Farrell]

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