Subject: [ietf-dkim] Misc. fairly minor issues

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Jul 2006 23:27:37 +0100

These don't all deserve an individual entry in the tracker, so maybe
just create one for the lot and we can spin out new ones if necessary
later.

Stephen.

#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?

#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. If it means something
else then I'm confused.

#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?

#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?

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

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

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

#8 3.4, 5th para ("In all cases...") is now incorrect since we have "bh=" 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.

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

#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?

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

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

#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?

#13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED, which is a bit
of a contradiction. 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=", however for the special case of "l=0" it seems
odd to include "bh=" at all. 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.

#14 3.5, "d=". The relationship between "d=" and "t=s" in the key record and
"i=" is a bit complicated. If it could be simpler that'd be good, but at least
a paragraph elsewhere explaining it (incl.  ASCII art?) would be good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 1 Jul 2006 21:46:19 -0400

One person's interpretation...

>rfc, then fine. If not, do we need to say something in case the mail 

RFC 2045 is probably sufficient for a mail implementer.

>selector is in foo.bar_domainkey.tcd.ie? I assume so.

Yep.

>long, coders might make bad assumptions here. What, if anything, are the max

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

>(VALCHAR in the ABNF). What if/when Unicode is allowed in headers?

It isn't.

>the ABNF? If so, does current code insist upon this?

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

>say that signers MUST use at least 1024 bit RSA moduli. (See also editorial #7

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.

>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

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

>headers now need to be normalised first.

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

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

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

>algorithms? I think that that might help cut out some corner cases.

That would be nice.

>The logic behind that replacement is that there is code and experience with

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

>of a contradiction.

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

>And "l=" is not mentioned when saying how to calculate
>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="

It also adds another special case.

>"i=" is a bit complicated.

Agree.

>If it could be simpler that'd be good, but at least

Agree.

>alternatives needed? (I hope not.)

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

>(where needed), but it doesn't say that.

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

>s.t. one says its a good key and the other says not. Just deleting 

Agree.

>don't care, but it should say.

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

>think this should be MUST for both.

Agree.

>key with a fixed public expontent == 65537.

s/expontent/exponent/; agree.

>input to dkim_find_key already so I think this sentence should go.

Agree.

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

>defined?

No, and in fact it is nonsensical.

>E.g. could it happen that sign-or-remove would be the wrong thing to

Agree.

>verifier MAY add something. The MAY is wrong since the something 

Agree.

>hard to tell from reading this section since so much is down to local policy.

It would be.

>verifier rule for that here. Suggest adding that.

Agree.

>include a max. after which they handle the message as a PERMFAIL.

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

>verifier MAY reject the key if its too short? (Could also be added to item #9

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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Jul 2006 07:23:11 -0700

>> #13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED, 

It doesn't seem valid to me, and it's certainly not the natural thing that
an implementor would do which is to just take the value of SHA[1|256]_Final
and compare it against the bh= value. Leaving it as is doesn't create an
unnecessary new case.

>> talking about calculating "bh=",

I don't see what the problem is: l= is the canonical byte count, and that's
just as true with bh as is was before bh was invented.

> It also adds another special case.

Not to mention that l=0 is a perfectly valid 2822 mail message.

          Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 Jul 2006 10:49:52 -0400

>and compare it against the bh= value. Leaving it as is doesn't create an

Oh, wait; Michael is completely right here. If l=0, bh= contains the 
hash of a zero-length string, which has the length of a normal hash 
output. My apologies.

>just as true with bh as is was before bh was invented.

The question is, what string do you hash when l= is given? I am 
interpreting the spec as that you has the string with the length 
given in l=; are you reading it as you hash the entire body 
regardless of the presence of l=?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Jul 2006 15:50:40 +0100

Mike,

> and compare it against the bh= value. Leaving it as is doesn't create an

I think I agree that "l=0;bh=;" is wrong, but I'm not clear what you're
saying that "bh=" should contain when "l=0"?

> Not to mention that l=0 is a perfectly valid 2822 mail message.

True,
S.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Jul 2006 08:36:27 -0700

Paul Hoffman wrote:

> interpreting the spec as that you has the string with the length given 
> in l=; are you reading it as you hash the entire body regardless of 
> the presence of l=?

No, the former lest l= mean nothing at all. I don't seem to recall this 
being an
interop problem in any of the implementations we have now either.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 Jul 2006 12:40:03 -0400

At 8:36 AM -0700 7/2/06, Michael Thomas wrote:
>No, the former lest l= mean nothing at all. I don't seem to recall 
>this being an

Ah, good. It would be good to add a sentence about this to the spec, then.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Jul 2006 09:48:39 -0700

> saying that "bh=" should contain when "l=0"?

Just the normal base 64 encoding of the 20 byte output of SHA1/SHA256 --
nothing different than normal, eg l= > 0.

          Mike, not knowing what those values are offhand :)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Jul 2006 10:46:19 -0700

>> selector is in foo.bar_domainkey.tcd.ie? I assume so.

The confusion here is that somebody might think that there is
a semantic meaning of a "sub-domain" with a DKIM selector
when as far as I can tell there is none. My selector in this mail contains
one of these beasts and as far as I can tell it's only to amuse me and
nothing more.

>> algorithms? I think that that might help cut out some corner cases.

I've tried to do this before and still have the pseudo code around, but
I think I've changed my mind about its utility -- there's such a chance
that there'd be a subtle bug (it's pseudo, after all) in it which we'd
introduce a difference between the normative text. Plus I've seen
disagreements here where it was actually the language of the code
that led to confusion where the normative text didn't have any mention
of the language in question. So I'd just assume we not go here...

>> "i=" is a bit complicated.

The incremental change here once you work through it really small
though (strcmp vs subdomainof).

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

I assume you mean simple equality of the strcmp variety?

>> s.t. one says its a good key and the other says not. Just deleting 

I've never been comfortable with that sentence either, but I'm pretty
sure we've been over this before and the consensus was against us.

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

I'm neutral as to how many we allow, but one thing we might remind people
of is that you shouldn't use off the shelf shell wildcard matching routines
since they allow ? and other stuff too.

Yep.

>> verifier rule for that here. Suggest adding that.

I think the section on h= (and the rest of the tags for that matter) is 
phrased in terms
of both signer and verifier. It seems pretty implicit that if a signer 
MUST do something
the verifier MUST make certain that signer did in fact conform. Maybe 
just a
general rule?

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Jul 2006 19:16:13 +0100

>          Mike, not knowing what those values are offhand :)

According to some code of mine, sha256("") in hex is:

248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1

Anyone confirm that? (I've not checked what the code does, vs.
should do, with a null input.)

So we should have "l=0;bh=base64(that-hex-above)"

S.

---

From: Mark Delany <[email-masked]>
Date: Sun, 2 Jul 2006 19:48:19 +0000

> 248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1

FreeBSD6 $ sha256 </dev/null
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

OSX $ shasum -a 256 </dev/null
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Jul 2006 22:37:43 +0100

> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

Yep - you're right, I'm wrong (forgot to zap a previous test vector),
S.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Peter Koch <[email-masked]>
Date: Mon, 3 Jul 2006 09:34:37 +0200

> selector is in foo.bar_domainkey.tcd.ie? I assume so. If it means something

first, I think you meant "foo.bar._domainkey.tcd.ie"?
Then, while "." is the DNS label separator, it is possible to have "."
within a label, but that needs proper escaping. Also, I'm not sure that
it works in all cases, although modern implementations should avoid those
pitfalls that arose from converting back and forth between wire and presentation
format in earlier days. This is similar to having one of these
[email-masked] addresses in the DNS SOA RNAME field.
Logically speaking, the "." in your example would really belong into the label.

-Peter

---

From: Mark Delany <[email-masked]>
Date: Mon, 3 Jul 2006 14:23:24 +0000

> Logically speaking, the "." in your example would really belong into the label.

The original text could probably benefit from using more accurate DNS
terminology.

The intent is that the string foo.bar is valid selector syntax and
that "foo" is one dns label and "bar" is another dns label. In other
words, a selector is not constrained to be a single label.

Back to Peter's concerns and example, I think the case is that the "."
in the Selector syntax is always interpreted as a dns label separator
as the syntax does not allow for that distinction between the two
interpretations. To do that, we would have to invent something like
"foo.bar"._domainkey syntax to mean that "foo.bar" is a single dns
label or maybe foo\.bar._domainkey.

That seems ugly and unnecessary - especially since DKIM already
imposed constraints on the contents of labels, this seems like another
acceptable constraint.

I hope that's the obvious interpretation. I base that on the likelihood
that a lot of people probably don't even realize you can have periods
in labels.

Mark.

---

From: Peter Koch <[email-masked]>
Date: Tue, 4 Jul 2006 17:17:52 +0200

> The original text could probably benefit from using more accurate DNS

sorry, I was picking on the missing "." in "foo.bar._domainkey.tcd.ie"
just to make sure I myself didn't get it wrong.

> label or maybe foo\.bar._domainkey.

Well, I don't think there's a new invention necessary, just a clarification
whether or not the selector makes up a single label. To me it looks
cleaner from the protocol POV to go for a single label, while there
are operational counterarguments.

> imposed constraints on the contents of labels, this seems like another

A word of clarification might be helpful here.

-Peter

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Jul 2006 09:22:17 -0700

John Levine wrote:

>CNAMEs can always loop, but that is a general problem that we aren't
>making any worse.
>  
>
It's my belief that DKIM selectors don't allow CNAME's. Am I correct?

       Mike

---

From: John Levine <[email-masked]>
Date: 4 Jul 2006 16:17:02 -0000

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

The intention was to allow sub addresses so if your MTA delivers all
addresses of the form fred+foo or fred-foo to fred, it can cover all
the versions.  I would suggest changing the wording and ABNF to permit
a * only at the end.  I can tell you from experience that coding
pattern matchers, even one for a single * in the middle, is tricky and
a rich source of obscure bugs, so I would prefer if the the patterns
were trivial.

>namely adding headers that mean something to the recipient.

The usual example is a plain text message without MIME headers to
which a bad guy adds headers making some random line in the message
into the MIME separator, thereby hiding everything in the message
above that.  It interacts particularly badly with l= since you could
add new MIME stuff at the end and make the original message completely
invisible.

R's,
John

---

From: John L <[email-masked]>
Date: Tue, 4 Jul 2006 15:57:40 -0400 (EDT)

> It's my belief that DKIM selectors don't allow CNAME's. Am I correct?

Nope.  A CNAME is just an indirect address.  For example, this would work 
with all the DNS implementations I know:

foo._domainkey.bar.com  CNAME farble.baz.org

farble.baz.org  TXT "normal dkim key record"

But as I said, CNAME loops have been a feature of the DNS for 25 years, 
and we're not making the situation any worse.  That's why Paul said 
queries that return a record or something like that.  CNAMEs are either an 
infinite loop or a chain that terminates.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Jul 2006 07:33:36 +0200

I wrote:
> A more practical use of CNAMEs regarding DKIM might be more like this:
>   
[broken example].  Make that...
> foo._domainkey.sub1.domain.com   CNAME foo._domainkey.domain.com
> foo._domainkey.sub2.domain.com   CNAME foo._domainkey.domain.com
> foo._domainkey.sub3.domain.com   CNAME foo._domainkey.domain.com
> foo._domainkey.sub4.domain.com   TXT "subdomain 4 key record"
> foo._domainkey.domain. com  TXT "normal domain key record"
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Jul 2006 07:31:23 +0200

John L wrote:
> Nope.  A CNAME is just an indirect address.  For example, this would
> work with all the DNS implementations I know:
>

foo._domainkey.sub1.domain.com   CNAME foo._domainkey.com
foo._domainkey.sub2.domain.com   CNAME foo._domainkey.com
foo._domainkey.sub3.domain.com   CNAME foo._domainkey.com
foo._domainkey.sub4.domain.com   TXT "subdomain 4 key record"
foo._domainkey.com  TXT "normal domain key record"

Eliot

---

From: Mark Delany <[email-masked]>
Date: Wed, 5 Jul 2006 07:55:28 +0000

> It's my belief that DKIM selectors don't allow CNAME's. Am I correct?

Whilst that might be appealing if one is no fan of CNAMEs, it would be
very hard to enforce. In particular an amount of DNS client software
follows CNAMEs automatically for the caller so a verifier may not even
get the chance to make this decision. One example being the popular
CPAN module Net::DNS::Resolver. It wouldn't surprise me if some caches
do this too making detection impossible in some cases.

Furthermore, disallowing CNAMEs would be inconsistent with most (all?)
other RR type queries thus creating surprise for unknowning DNS admins
who might routinely use CNAMEs.

Which maybe brings up a documentation clarification about allowing
CNAMEs since at least one person assumed that they are not allowed.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Wed, 5 Jul 2006 08:15:34 +0000

> are operational counterarguments.

If it weren't for allowing periods in a Selector I would agree that a
Selector should be treated as a single label.

But allowing a period implies some implementation counter arguments
too. In particular the standard client libraries I've used don't allow
you to issue queries with periods in labels. Nor as far as I can tell
do the standard Unix command line tools.

So, having a selector as a single label might have some appeal, I
suspect that the confusion over periods would be quite significant.

As far as I recall the rationale for periods was primarily
operational. Beauty is in the eye of the beholder, but:

	s1_zurich._domainkey.ibm.com
	s2_zurich._domainkey.ibm.com

strikes me as less manageable (and more ugly) than:

	s1.zurich._domainkey.ibm.com
	s2.zurich._domainkey.ibm.com

Regardless, Peter makes a good point, we should ratify and clarify the
meaning of periods in a Selector.

Mark.

---

From: Peter Koch <[email-masked]>
Date: Wed, 5 Jul 2006 10:11:35 +0200

> CNAMEs since at least one person assumed that they are not allowed.

from the DNS point of view you don't need to say anything. Usual DNS
resolution rules apply. If you start discussing CNAME, what about DNAME?

The problem might be one of wording, since 3.6.2.1 says that the keys are
``"stored" in a subdomain named ""_domainkey""'', where that's actually
the (sub)domain used to query for them. An example using CNAME might be
helpful as well.

-Peter

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Jul 2006 08:37:52 -0700

>CNAMEs since at least one person assumed that they are not allowed.

I guess I'm uncomfortable with CNAME's because I don't understand their
effects on the protocol very well, and in particular the security 
ramifications.
First off, lets suppose DKIM's query mechanism were a lot like it is 
today, but
the base mechnism didn't have CNAME's. Suppose that somebody proposed
that we should introduce them as a feature. What are:

1) The benefits in general
2) The security implications of the base DKIM mechanism (ie, is the 
delegation
    model still correct, what about key rollover, etc, etc).
3) The unintended security implications (loops, dos, amplification...)

Would we adopt that proposal at all? If the answer is "no", then that
sort of implies that we should at least discourage their use and/or have 
a good
bit of information about their use, most likely in the security 
considerations.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Jul 2006 08:50:50 -0700

>meaning of periods in a Selector.
Speaking to JD Falk, actually putting selectors within heirarchical 
subdomains could
have the interesting property of an easy way for an operator segregate 
out the "type"
of traffic certain selectors emit, and thus allow you to aggregate 
reputation to that
subdomain boundary. All out of scope for -base, of course, but leaving 
it the way we
have it now allows us to do these sorts of experiments going forward 
without having
to djinn up a new piece of punctuation for an aggregation point.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Wed, 5 Jul 2006 16:16:25 +0000

> resolution rules apply. If you start discussing CNAME, what about DNAME?

Quite so. I note that, eg, RFC2821 spends some time discussing CNAMEs,
but on the resolving side merely to say "resolve as usual".

> the (sub)domain used to query for them. An example using CNAME might be

Yep. In light of the possible confusion I also wonder whether a
multi-label Selector should also be discussed or inferred by example.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Wed, 5 Jul 2006 16:24:24 +0000

> that we should introduce them as a feature. What are:

[ the costs, risks, benefits ]

While interesting, as a practical matter, most verifiers would have to
go to extraordinary length to reliable detect CNAMEs so I think the
question is mostly moot unless it can be shown that there is a risk
unique to DKIM.

Mark.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 5 Jul 2006 09:31:57 -0700

> multi-label Selector should also be discussed or inferred by example.

Definitely. In order to do stunt-dns-server tricks, as will be needed  
to make
key management for ESPs tolerable, multi-atom selectors are a must, and
it would be annoying if we had to go through a phase where some DKIM
validators got that case wrong.

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Jul 2006 20:29:03 +0200

> 1) The benefits in general

Consolidation of multiple domains to a single key record.  Useful when
contracting out signing, wouldn't you think?

>    model still correct, what about key rollover, etc, etc).

You own the domain.  If you CNAME over to somebody else you're trusting
them.
> 3) The unintended security implications (loops, dos, amplification...)

Dunno.  Mark's points apply.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Jul 2006 12:11:03 -0700

On Jul 5, 2006, at 9:31 AM, Steve Atkins wrote:

> Definitely. In order to do stunt-dns-server tricks, as will be  
> needed to make

The need for multi-label selectors could support the segregation of  
key delegations as suggested in the last sentence of section 1.1.

In section 3.1,

,---
| "Periods are allowed in selectors and are component separators."
'___

  change to:

: "A period contained within the The DKIM-Signature header field
: selector "s=" tag delineates separate domain node labels.

Also:
,---
| While some domains may wish to make selector values well known,
| others will want to take care not to allocate selector names in a way
| that allows harvesting of data by outside parties.  E.g., if per-user
| keys are issued, the domain owner will need to make the decision as
| to whether to associate this selector directly with the user name, or
| make it some unassociated random value, such as a fingerprint of the
| public key.
'___

  change to:

: While some domains may wish to make right-most selector labels
: represent well known values, others will want to take care not to
: allocate selector names in a way that allows harvesting of data by
: outside parties.  E.g., if per-user keys are issued, the domain
: owner will need to make the decision as to whether to associate
: selector labels directly with the user name or a category of messages,
: or make it some unassociated random value, such as a fingerprint of
: the public key.

Adding a right-most label clarification allows the selector to offer  
both separate accruals and key updates without conflict.

I don't see any specific concerns related to the use of CNAMES except  
to suggest this as a technique for consolidating keys, which in  
general seems like a bad practice.  Not offering CNAME examples seems  
like a good choice.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Jul 2006 13:09:51 -0700

>question is mostly moot unless it can be shown that there is a risk
Well, here's one: DKIM often runs during the incoming SMTP conversation
with its inherent timeouts. Can attackers exploit that fact? What should a
developer do to minimize risk?

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 5 Jul 2006 13:26:24 -0700

On Jul 5, 2006, at 1:09 PM, Michael Thomas wrote:

>>> First off, lets suppose DKIM's query mechanism were a lot like it  
>>> is today, but

Have a reasonable timeout on any DNS query, treat the message as
unsigned if the public key cannot be retrieved?

There doesn't appear to be any DNS-related risk to the recipient of
the message, as long as the verification code is written with some
care. There are lots of things the sender can do (and a few things a
third party could do) that would break the DNS related bits of DKIM,
but I can't think of a case where anything worse than some excess
DNS traffic followed by the message being treated as unsigned
would happen.

Cheers,
   Steve

---

From: Mark Delany <[email-masked]>
Date: Wed, 5 Jul 2006 20:33:13 +0000

> developer do to minimize risk?

Can you elaborate on how CNAME in particular comes into play here?

If the SMTP server does any DNS queries at all, whether that be for
DKIM, reverse mapping, RBLs, PKIX servers or any other modern-day
goop, then those queries can easily have CNAMEs in the chain. Even
just following the NS tree down to the authoritative server for the d=
domain in question can easily have CNAMEs that a client/cache already
follows today.

The only question can be, does a CNAME immediately prior to the final
TXT/DKK RR add a threat that is different from CNAMEs encountered
earlier in the lookup process.

Mark.

---

From: David Mayne <[email-masked]>
Date: Wed, 05 Jul 2006 18:15:09 -0700

> contracting out signing, wouldn't you think?
Strongly agreed - an ISP that supports millions of hosting domains, for 
instance, will see a administrative barrier to using DKIM without 
CNAME's, at least to get started.

Thanks,

David

---

From: John Levine <[email-masked]>
Date: 6 Jul 2006 02:07:33 -0000

>> contracting out signing, wouldn't you think?

Maybe.  Adding a CNAME is no easier than adding a TXT record.  A
difference is that if you have many CNAMEs pointing to one place for
the TXT, you can change what's at the place once and it changes
everywhere else.

>CNAME's, at least to get started.

Again, seems to me that to get started adding a TXT and adding a CNAME
are the same amount of effort.

There are two general scenarios where CNAMEs are useful.  One is when
you are changing the name of a domain, and use a CNAME to alias the
old domain tree to the new one for a transition period.  The other,
more interesting, one is when the zone with the CNAME and the zone of
its target are under different management.  For contracting out, a
CNAME could be quite useful to point your _domainkey subdomain at
someone else's nameserver so that someone else can do all the key
management.  This applies even if every CNAME points to a different
place -- the goal is to give the owner of the target of the CNAME the
ability to change what's there without letting them mess with the rest
of your zone.

Note that all of this is well known in the DNS community.  We're just
applying existing tools to our slightly unusual DNS application.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Thu, 6 Jul 2006 03:26:55 +0000

> are the same amount of effort.

I suspect that this is subjective and very much depends on how an ISP
might choose to deploy and what sort of database they use to generate
their zones. In any event, this seems like an argument against CNAME
support yet you then go on to say CNAMEs should be treated as
normal. I guess I'm confused as to the point?

In any event, maybe it's all a nit as the very question about
supporting CNAMEs really seems to be a non-issue. Unless there is
compelling reasons, let's just continue with the obvious and use the
DNS as everyone else does and use standard DNS resolving algorithms
and libraries as everyone else does. End of story.

Mark.

---

From: David Mayne <[email-masked]>
Date: Wed, 05 Jul 2006 19:51:57 -0700

John Levine wrote:
>   A
That is the main administration issue that CNAME's simplify that I meant 
to confer, yes. It could be a big deal for service providers,  having 
the changes in one place for domains that don't opt in for custom keys. 
While the effort to put in TXT records and CNAMES may be seemingly the 
same, the subsequent management is what I'm concerned with - and it is 
hard for me to put something into place if I can't find a way to manage it.
>  The other,
> management. 
More interesting, yes, but I think that management of the keys, even 
within an organization like a hosting ISP that has control of DNS, is 
still an issue to be dealt with, given the number of domains/entries 
involved, and that CNAME's do offer a viable management point today.

Thanks,

David

---

From: John Levine <[email-masked]>
Date: 6 Jul 2006 04:12:05 -0000

>normal. I guess I'm confused as to the point?

Hey, I'm a liberal, I argue against myself.

a) there are some potentially interesting ways to use CNAMEs to manage
DKIM keys.

b) every DNS implementation on the planet already has CNAME support
that's invisible to clients like us, we're not going to change that,
so don't worry about it.

R's,
John

---

From: Eric Allman <[email-masked]>
Date: Fri, 07 Jul 2006 16:33:23 -0700

I've deleted the points where I have nothing to add to Paul's 
comments.

> used in tags that list headers; there are lots of other tags.

It's incorrect because the paragraph talks about sending the CRLF 
followed by the canonicalized body.  This algorithm is presented 
elsewhere though --- does anyone object to just removing this 
paragraph entirely?

>> #13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED,

(I think this has already been discussed.)  "l=0;bh=;" is not valid. 
There is always a bh= value, even if it is just the hash of the 
zero-length string.

>> "bh=". I guess the right thing to do might be to add some mention
>> of "l=" when talking about calculating "bh=",
>
> Agree.

I changed the first line of the bh= description to read "The hash of 
the body part of the message as limited by the "l=" tag (base64; 
REQUIRED)."

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

Could someone please propose simpler wording?

>> a paragraph elsewhere explaining it (incl.  ASCII art?) would be

I'm not at all clear how ASCII art would apply here.

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

I disagree.  If you list multiple key query mechanisms, and the 
semantics change depending on which one gives you the answer, isn't 
this just asking for trouble?  If you want different semantics, you 
should have two separate signature header fields.

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

As already noted, simplicity.  There was a comment that it should 
only allow "*" at the end, but this would limit the applicability, 
e.g., for companies that had a class of addresses that all ended in 
"-foo".  Is this a large enough use case?  I don't know.

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

My recollection is that we had agreed that signers MUST support 
sha256 and that verifiers must support both.  On this assumption I 
changed the wording to "Signers and Verifiers MUST support the 
"sha256" hash algorithm.  Verifiers MUST also support the "sha1" hash 
algorithm."  If we want to make both algorithms a MUST on both sides, 
it's easy to do so.

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

It's looking like there is no reason to limit it to a single 
exponent, so this is pending removal.

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

I guess.  I still disagree with removing it from dkim_find_key 
though, since it might be used for other query mechanisms.  C'est la 
vie.

>> #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?
>

I can see that this doesn't make sense here because the signer 
doesn't know what header fields will be used to convey this 
information on the verifier side.  However, the verifier should be 
sure to remove such fields so that a spoofer can't just insert a 
header asserting that the message was properly signed.  With this in 
mind, I've added the sentence "Verifiers may wish to delete existing 
results header fields after verification and before adding a new 
header field to circumvent this attack" to the end of the informative 
advice paragraph in 6.2.

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

The point here is that the verifier is allowed to convey 
authentication status in the header.  Why is this not a MAY?

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

I added a paragraph reading "If the "h=" tag does not include the 
"From" header field the verier MUST ignore the DKIM-Signature header 
field and return PERMFAIL (From field not signed)."

eric

---

From: Mark Delany <[email-masked]>
Date: Sat, 8 Jul 2006 00:23:23 +0000

> "-foo".  Is this a large enough use case?  I don't know.

I'm going to suggest that this could be a can of worms as the
wildcarding is not well define and thus could be interpreted
differently. Paul's query about "*s*t*. etc" makes that point. Also,
as I understand it, regex is a notoriously ambiguous topic matter.

Can I suggest that this is worthy of adding as a tracking item for
Eliot to add? We need a clear definition of wildcard evaluation. Can
we reference something? Posix perhaps? wildmat() out of INN perhaps?

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 07 Jul 2006 17:32:17 -0700

Eric Allman wrote:
> I've deleted the points where I have nothing to add to Paul's comments.
>
I think we need to say "canonicalized" somewhere there, as in "hash of
the canonicalized body".
> Could someone please propose simpler wording?
I'm doing a good job at coming up with more complex wording, but that's
not really helpful.  The relationship between i=, d=, and the t=s flag
of the key record is subtle enough that perhaps it should be a separate
section, e.g., 3.8.  Then we might have:

d=   The domain of the signing entity (plain-text; REQUIRED).  This
       is the domain that will be queried for the public key.  This
       domain MUST be the same as the domain of the "i=" tag
       (the signing identity, as described below), or it MUST meet the
       requirements for  parent domain signing described in section 3.8.
      When presented with a
       signature that does not meet these requirement, verifiers MUST
       consider the signature invalid.

=====

3.8 Signing by parent domains

In some circumstances, it is desirable for a domain to apply a signature
on behalf of any of its subdomains without the need to maintain separate
selectors (key records) in each subdomain.

By default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside,
e.g., a key record for the domain example.com can be used to verify
messages where the signing identity (i= tag of the signature) is
sub.example.com, or even sub1.sub2.example.com.  In order to limit the
capability of such keys when this is not intended, the t=s flag of the
key record can be used to constrain the validity of the record to
exactly the domain of the signing identity.

If the referenced key record contains the t=s flag, the domain of the
signing identity (i= flag) MUST be the same as that of the d= domain. 
If this flag is absent, the domain of the signing identity MUST be the
same as, or a subdomain of, the d= domain.

Key records which are not intended for use with subdomains SHOULD
specify the "t=s" flag.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 08 Jul 2006 12:01:50 +0100

> Key records which are not intended for use with subdomains SHOULD

Looks good to me.
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 08 Jul 2006 11:57:53 +0100

Just on this one. I think the others are mainly done or fairly
easy.

Eric Allman wrote:

> semantics change depending on which one gives you the answer, isn't this 
> just asking for trouble?  If you want different semantics, you should 
> have two separate signature header fields.

That might be a good idea all right, but if that's the plan we
should say it, and say when a new DKIM-signature vs. a new
q= value is appropriate (a hard problem, IMO).

Even so though, say if someone defines q=xkms to mean "ask your
local trusted xkms responder for a valid key for this domain".
Now say the key is revoked using an X.509 crl but word spreads
slowly (which it can, via different local timeouts, nextUpdate
fields, ocsp caches, etc.) so that different verifiers will get
different results for some time period. Does that count as
different semantics? If not, then what does?

So given that there will always be grey areas here I'm not sure
how we can get all signers to do the right thing.

One other thing - what "trouble" are we asking for if different
verifiers get different results? Seems like it'll happen anyway
after signature verification (at higher layers), so its maybe not
that much of a problem if signature verification can also depend
on local things like which q= a verifier prefers.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 08 Jul 2006 07:51:05 -0700

> > Key records which are not intended for use with subdomains SHOULD

Rather than specifying specifically "the t=s", as this could also be
"t=x:y:z:t:s".  Perhaps this could be expressed as "the 's' flag
contained within the key record 't=' tag value."

-Doug

---

From: Tony Hansen <[email-masked]>
Date: Sat, 08 Jul 2006 23:35:41 -0400

Eric Allman wrote:
> elsewhere though --- does anyone object to just removing this paragraph
> entirely?

Alternatively, remove the sentence "The CRLF ... body.". The rest of the
information still seems to be useful supportive text.

> There is always a bh= value, even if it is just the hash of the

correct

> I changed the first line of the bh= description to read "The hash of the
> body part of the message as limited by the "l=" tag (base64; REQUIRED)."

+1 with Jim's change to say "canonicalized body"

> Could someone please propose simpler wording?

How about separating out the syntactic and semantic descriptions of d=,
i= and t=s? That is, leave the syntactic description there, but with a
forward reference to another section. That other section gives the
semantic description of the three values and their interaction.

> have two separate signature header fields.

I agree; the semantics of a DKIM signature had better not change
depending on which key query mechanism returned an answer.

> As already noted, simplicity.  There was a comment that it should only
> allow "*" at the end, but this would limit the applicability, e.g., for
> companies that had a class of addresses that all ended in "-foo".  Is
> this a large enough use case?  I don't know.
> 
> My recollection is that we had agreed that signers MUST support sha256
> and that verifiers must support both.  On this assumption I changed the
> wording to "Signers and Verifiers MUST support the "sha256" hash
> algorithm.  Verifiers MUST also support the "sha1" hash algorithm."  If
> we want to make both algorithms a MUST on both sides, it's easy to do so.

We had agreed that the MUST for both algorithms was only on the
verifier, and the MUST for signing was just for sha256.

> I can see that this doesn't make sense here because the signer doesn't
> know what header fields will be used to convey this information on the
> verifier side.  However, the verifier should be sure to remove such
> fields so that a spoofer can't just insert a header asserting that the
> message was properly signed.  With this in mind, I've added the sentence
> "Verifiers may wish to delete existing results header fields after
> verification and before adding a new header field to circumvent this
> attack" to the end of the informative advice paragraph in 6.2.

+1

> The point here is that the verifier is allowed to convey authentication
> status in the header.  Why is this not a MAY?

I know that there is a push against being specific here as to what is
added, but I think we really need to keep this concept alive and well.
If we were being specific about using Authentication-Results, I'd even
want to make it a SHOULD or even a MUST. But just because we've watered
it down this much doesn't mean we should get rid of it entirely.

Keep it a MAY at the minimum.

> I added a paragraph reading "If the "h=" tag does not include the "From"
> header field the verier MUST ignore the DKIM-Signature header field and
> return PERMFAIL (From field not signed)."

+1

	Tony Hansen
	[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 09 Jul 2006 09:17:29 +0100

Hi Tony,

> depending on which key query mechanism returned an answer.

Maybe we're talking at cross-purposes? (Or maybe not.) The fact is
that different instances of key servers will give different key
valid/invalid results when different verifiers query for the key
and its status. Even the DNS can do that with caching and/or
in the face of network problems. With some other types of server
there can be even harder cases (e.g. "onHold" from X.509 based
ones). That does change the signature result from say, good,
to presumably PERMFAIL, but is it a change in signature semantics?

Or, how about if the verifier, using X.509 based certificate
checking, has some certificate policies configured (those are
part of the certificate validation algorithm and will have
been processed inside the rfc3280 code in that case). I know its
a bit silly sounding but policyMapping extensions in intermediate
CA certs can then affect the certificate validation result.
This means that verifiers in some parts of the PKI (say outside
the US federal govt) will see the certificate as good, whereas
others (say those inside the US federal bridge CA domain) will
find the certifcate invalid. Several bridge CA setups do
actually use this kind of extension as it happens (not that
that's a good idea IMO, but its a fact, e.g. [1]).

Cheers,
Stephen.

[1] http://www.cio.gov/fbca/documents/altermanpaper.pdf

---

From: Mark Delany <[email-masked]>
Date: Sun, 9 Jul 2006 13:56:20 +0000

> Keep it a MAY at the minimum.

As an alternative, does it make sense to get more specific and spell
out the Authentication-Results header as much as is needed and then
when the real Authentication-Results spec comes along can it say
"supersedes the definition in DKIM" or some such?

We could even go so far as to spell out that anticipation if it helps.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Jul 2006 13:36:04 -0400

> We could even go so far as to spell out that anticipation if it helps.

1. Interim never is.

2. Trying to specify an auth-res header ensures that we get enmeshed in that as
a new topic, prior to getting the base spec out the door.

3. Trying to anticipate how an independent bit of work will complete usually
leads to being wrong and losing synchrony with that work.

3. There is nothing in the base service that requires that we specify a
standardized mechanism for communicating authentication results to some outside
entity.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Eric Allman <[email-masked]>
Date: Sun, 09 Jul 2006 09:01:07 -0400

Stephen, I think I see your point, but only up to a point.  It would 
clearly be bad (ludicrous) to have the signature work on a key from 
one server type and fail on a key from another server type.  I 
suppose we could delete the sentence in question because that 
scenario is clearly not in the best interests of the signer.

I guess this should go on the issues list for the meeting.

eric

--On July 8, 2006 8:57:53 AM +0100 Stephen Farrell 
<[email-masked]> wrote:

>>>> 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.
>>
>> semantics change depending on which one gives you the answer,
>> isn't this  just asking for trouble?  If you want different
>> semantics, you should  have two separate signature header fields.
>

---

From: Eric Allman <[email-masked]>
Date: Sun, 09 Jul 2006 08:55:43 -0400

--On July 7, 2006 2:32:17 PM -0700 Jim Fenton <[email-masked]> 
wrote:

> Eric Allman wrote:
> ...
>> I changed the first line of the bh= description to read "The hash
>> of the body part of the message as limited by the "l=" tag (base64;
>> REQUIRED)."
> I think we need to say "canonicalized" somewhere there, as in "hash
> of the canonicalized body".

Agreed.

> I'm doing a good job at coming up with more complex wording, but
> that's not really helpful.  The relationship between i=, d=, and
> the t=s flag of the key record is subtle enough that perhaps it
> should be a separate section, e.g., 3.8.  Then we might have:
> (actual text deleted)

That's great --- thanks Jim.  I did modify it somewhat to incorporate 
Doug's suggestion.

eric