[ietf-dkim] Misc. fairly minor issues

[Paul Hoffman]

One person's interpretation...

>#1 2.6. How would multibyte characters be handled? If its clear from 
>the quoted
>rfc, then fine. If not, do we need to say something in case the mail 
>i18n folks
>(eai) get going?

RFC 2045 is probably sufficient for a mail implementer.

>#2 3.1  Just checking. This part says: "Periods are allowed in selectors and
>are component separators.  If keys are stored in DNS, the period defines
>sub-domain boundaries." Does that mean that the lookup for tcd.ie's foo.bar
>selector is in foo.bar_domainkey.tcd.ie? I assume so.

Yep.

>#3 3.2 Tags. We say nothing about the max. lengths for either tags or values.
>Given that all but one of the currently defined tags are only one character
>long, coders might make bad assumptions here. What, if anything, are the max
>lengths for these?

'tag-name  =  ALPHA 0*ALNUMPUNC' seems to clearly say "it can be any 
length greater than zero".

>#4 3.2 Tags. As with #1, we assume single byte characters here in tag values
>(VALCHAR in the ABNF). What if/when Unicode is allowed in headers?

It isn't.

>#5 3.2 Just checking. Is the final ";" always really necessary as indicated by
>the ABNF? If so, does current code insist upon this?

It isn't necessary; it is optional as indicated by [ ";" ]

>#6 3.3.4 says signers MUST use 1024 for *long-lived* keys, but we never say
>what long-lived means. I think we need to delete the term 
>"long-lived" and just
>say that signers MUST use at least 1024 bit RSA moduli. (See also editorial #7
>below.)

Fully disagree. Given the known attacks on RSA, keys shorter than 
1024 bits are useful for short periods of time (such as a week or 
month), and will be for many years in the future, particularly for 
the low value of short-term DKIM keys. See RFC 3776 (BCP 86) for the 
math.

>#7 3.4 Starts "Empirical evidence demonstrates..." so shouldn't there be a
>reference? (This isn't just editorial - if there is quotable evidence that may
>help the WG in closing some issues.)

There are no RFCs that demonstrate this.

>#8 3.4, 5th para ("In all cases...") is now incorrect since we have "bh="

Not sure why this is incorrect. The sentence is about the headers 
used in tags that list headers; there are lots of other tags.

>And
>when fixing this try be careful to talk about the signing algorithm as
>rsa-sha256 and not rsa, i.e. hashing takes place *inside* the signing API - so
>no-one outside sees the hash.

This paragraph should not list signing algorithms at all. If it did, 
it should list the algorithm fully as rsa-sha256, of course.

>#9 3.4 Last para. I18n again - we may need more instructions here if the
>headers now need to be normalised first.

They don't with any of the standards we are dealing with.

>#10 3.4.1 Just checking. When the value of a z= header field is fed into
>simple, the spaces that are quoted remain quoted, right?

Correct.

>#11 3.4.2 Just checking. The relaxed form of "  =20  " is a single space,
>right? Or is it " =20 "?

The latter. None of the five bullets talk about undoing QP.

>#12 3.4 generally. Could we get someone to volunteer some pseudocode for these
>algorithms? I think that that might help cut out some corner cases.

That would be nice.

>#12 3.4.4 Why not replace this algorithm with the S/MIME c14n alg (of pgp's).
>The logic behind that replacement is that there is code and experience with
>those body c14n's?

Or, better, why not get rid of it, as discussed in a different thread?

>#13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED, 
>which is a bit
>of a contradiction.

"l=0;bh=;" seems valid.

>And "l=" is not mentioned when saying how to calculate
>"bh=". I guess the right thing to do might be to add some mention of "l=" when
>talking about calculating "bh=",

Agree.

>  however for the special case of "l=0" it seems
>odd to include "bh=" at all.

Disagree.

>I think I'd prefer to outlaw "l=0" and make "bh="
>optional for just that case, but that might be a bit broken for backwards
>compatability.

It also adds another special case.

>#14 3.5, "d=". The relationship between "d=" and "t=s" in the key record and
>"i=" is a bit complicated.

Agree.

>If it could be simpler that'd be good, but at least
>a paragraph elsewhere explaining it (incl.  ASCII art?) would be good.

Agree.

>#15 3.5 "d=" says that idns names MUST be punycoded and depending on stuff,
>might have to be the same as in "i=". Does the dkim verifier have to 
>be able to
>handle only binary comparisons of the punycode or is support for any
>alternatives needed? (I hope not.)

The punycode is straight ASCII, so there is no "binary comparison". 
It is simple equality.

>#16 3.5 "i=" if "d=" MUST be punycode, then so must the domain part of "i="
>(where needed), but it doesn't say that.

Good catch. The same sentence for d= should be in i= as well.

>#17 3.5 "q=" says that different mechanisms MUST NOT change the interpretation
>of the signature. I don't think we can require that since different key
>services (e.g. xkms, scvp) may have different information about the public key
>s.t. one says its a good key and the other says not. Just deleting 
>the sentence
>should be ok though.

Agree.

>#18 3.6.1, "g=". Is "g=*s*t*e*p*h*e*n" allowed or is one "*" the limit?  I
>don't care, but it should say.

Good catch. Why does the definition for key-g-tag-lpart only allow one "*"?

>#19 3.6.1, "h=". This says MUST sha1 but the text never mentions sha256. I
>think this should be MUST for both.

Agree.

>#20, 3.6.1, "k=". This would be a good place to say (again) that "rsa" means a
>key with a fixed public expontent == 65537.

s/expontent/exponent/; agree.

>#21, 3.6.2.1 Says that "i=" is not used for DNS, but you removed that as an
>input to dkim_find_key already so I think this sentence should go.

Agree.

>#22, 5.4 Says "The signer MAY include more header field names than there are
>actual corresponding header fields to indicate that additional 
>header fields of
>that name SHOULD NOT be added." Is this feature needed? Seems like 
>it just adds
>complexity, in particular to the verifier and may be a source of bugs.

It prevents a MITM attack that many people think is significant, 
namely adding headers that mean something to the recipient.

>#23, 5.5 Says "To avoid possible ambiguity, a signer SHOULD either sign or
>remove any preexisting header fields which convey the results of previous..."
>Is it wise to include a SHOULD referring to a header field that's not yet
>defined?

No, and in fact it is nonsensical.

>E.g. could it happen that sign-or-remove would be the wrong thing to
>do, if the signer couldn't verify the assertion in that field but perhaps the
>verifier could? Note: while such a scheme could be invented, I am 
>not saying it
>ought be. (Same issue crops up in last sentence of the next para.)

Agree.

>#24, same issue as #23 occurs in section 6 2nd para, where it says that a
>verifier MAY add something. The MAY is wrong since the something 
>isn't defined.

Agree.

>#25, 6.1. Just checking. Would an implementation that only tries to verify one
>single signature ever (regardless of how many are present) be compliant?  Its
>hard to tell from reading this section since so much is down to local policy.

It would be.

>#26, 6.1.1. Section 5 says that "From" MUST be signed. I expected to see a
>verifier rule for that here. Suggest adding that.

Agree.

>#27, 6.1.2, list #4. This is probably dumb, but I'm not afraid to embaras
>myself:-) Is there any way someone could cause the DNS to loop, returning a
>stream of (presumably bogus) public key records? If not, fine (and I suspect
>that this is the case).  If so, then we might want to advise verifiers to
>include a max. after which they handle the message as a PERMFAIL.

Current DNS RRtypes which result in a leaf record will not loop.

>#28, 6.1.1, list. Should we add another item to the list to the 
>effect that the
>verifier MAY reject the key if its too short? (Could also be added to item #9
>in the list.)

No. The Verifier MAY reject the key if it was created on the first 
Tuesday of the month, but we do not need to list that.