William, thanks for your comments. Responses inline.
william(at)elan.net wrote:
1. Selector
It is not clear what subdomain is used for public key. In 3.7.2.1
it says that "DKIM keys are stred in a _domainkey subdomain" where
as example in B.3 uses "brisbane._dkim.example.com".
_domainkey is correct; it was chosen in order to allow existing
DomainKeys keys to be reused for DKIM.
Personally I think you should drop specifying some particular subdomain
(I did even in first META draft) as requirement and make it part of the
selector itself - you alread allow it to include "." so its not much
of a
difference. The change would be from:
DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com;
to:
DKIM-Signature: a=rsa-sha1; s=brisbane._dkim; d=example.com;
Note: you can also probably integrate "d" with "s" too but them
being separate might be useful, more discussions are needed.
One concern with making the prefix (_domainkey) explicit is that it
might allow too much flexibility; if for some reason unrelated to
message signing one needs to delegate _foo.example.com, it may not be
intended that the delegatee have the ability to create selectors and
start signing mail. If you left out the underscope on the prefix, it
might be possible to use s=brisbane.example; d=com and suddenly
example.com would be able to sign for .com, which is clearly
unacceptable. We need to keep "d" and "s" separate in order to know
where to insert the _domainkey in the query and to enforce the parent
domain rule ("d" must be the same as, or a superdomain, of the "i" address).
2. Signing
From section 3.3.1 -
"The hash MUST NOT be truncated or converted into any form other than
the native binary form before being signed."
Native binary form is different from one system to another. You need to
specify byte order used for data sitning or not use above line.
We should probably be specifying network byte order or something.
3. Key Size
From section 3.3.2 -
"The practical constraint that a 2048 bit key is the largest key that
fits within a 512 byte DNS UDP response packet"
That is not entirely true. Because you use BASE64 within DNS TXT record
and because respose is not really 512byte dns udp for data (i.e. it
would include dns "question" and "authority" in addition to "answer").
The 2048 bit key will not fit in dns.
This has been answered by others.
4. Version tag
From section 3.5 -
"Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Valid tags are:
v= Version (MUST NOT be included). This tag is reserved for future use
to indicate a possible new, incompatible version of the specification.
It MUST NOT be included in the DKIM-Signature header field."
I understand your intent but above is funny to say the least, plus in
light of the fact that in some other part of the spec it says that
unknown tags are to be ignored, it would be wrong. What you should
probably say is that "v" is reserved tag and if verifying agent
confirming to this spec encounters "v" tag it should abort processing
and consider it to be incompatible header and abort processing.
I thought this was what it is saying, i.e., if the v= tag is present it
is incompatible with the current version of the spec.
However personally I think you should specify 1.0 as default version
and say that it MAY be added but its not required and that if "v"
tag is not present the header field should be processed as if it
had default "1.0" version tag
The rationale here is to avoid defaults as much as possible. I don't
see any functional difference between "no version" and using version 1.0
as you have suggested.
5. Header field reordering:
From section 3.5 -
"The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in section 3.6 of [RFC2822], and hence
SHOULD NOT be reordered and SHOULD be kept in blocks prepended to the
message. In particular, the DKIM-Signature header field SHOULD precede
the original email header fields presented to the canonicalization and
signature algorithms."
First of all these SHOULD may well have to be MUST consider that you
have quite a bit depending on that reordering does not happen. Second
RFC2822 really does not say that trace fields should proceed other
fields and should not be reordered. The only thing it says is that
trace fields should not be reordered in relation TO EACH OTHER and
that is different statement - that should be mentioned if you're
comparing to RFC2822 defined trace fields
There are two separate issues here:
1. The suggestion that the DKIM-Signature be treated as a trace header
field needs to be a suggestion because it's hard to retroactively rule a
previously-unknown header field is a trace header field. This
suggestion is made in order to minimize breakage when multiple
DKIM-Signatures are present, and all that is being asked is that they
not be reordered with respect to each other. This allows
DKIM-Signatures to potentially sign other DKIM-Signatures, although we
haven't precisely defined how that should or could work.
In other respects, the order of signing headers is defined by the
ordering of the tags in the h= value, and in the case of duplicate
headers, the "bottom-up" rule (in section 5.2.2) applies. The only
ambiguity occurs when a non-standard header field is signed which occurs
more than once at the recipient, since these can be reordered. Section
5.2.2 also recommends against signing such header fields.
6. DNS RR
From section 3.7.2.2 -
"Verifiers SHOULD search for a DKIM RR first, if possible, followed by a
TXT RR. If the verifier is unable to search for a DKK RR or a DKK RR is
not found, the verifier MUST search for a TXT RR."
First of what is "DKIM RR" - I assume you meant "DKK RR". Second is that
above system (copied from SPF) would lead to double the necessary number
of queries. This is not SPF and you have email message with data space
available where you can actually say which RR to check (something that
I saw and took care of immediatly even in absolute MTA Signatures first
spec year ago). The simplest for DKIM syntax is to specify type of
record
as part of "q" tag and instead of using "dns" to mean above search in
DKK RR and TXT RR, specify that "dns/dkk" means search dkk rr is present
and "dns/txt" means that txt record is present. You can still do default
"dns" and specify that with your search algorithm if you want, but I'd
say that having particular available RR specified should be considered
RECOMMENDED.
The potential issue here is that the signer doesn't know whether the
verifier has the capability to use DKK RRs, possibly due to a
restriction such as a firewall. The signer therefore still needs to
publish TXT, although this would let the recipient know that DKK exists
and save a query in the event that it doesn't.
Also note that rationale for "verifiers and signers MUST support dns"
is unclear to me. Either you want new algorithms supported or you do
not but specifying that they "MUST" support dns means that you can
not have anything other then "q=dns,newquerytype" where as I think
you want to allow just "q=newquerytype"
The whole issue of upgrading to new mechanisms is problematic, since the
signer and verifier can't negotiate with each other. It will probably
need to be a gradual process, with the dns querytype continuing to be
supported well into the future. In any case, a new mechanism will
require a revision of the spec and this can be relaxed when appropriate.
7. Use of copied haeders "z" tag
Use of copied headers that are in "z" tag is not specified very well
and the syntax for using "z" tag maybe problematic (I'll discuss this
later most likely). The particular issue is that "h" how says that
header fields that appear more then once now have to be explicitely
listed one by one (i.e. h= Resent-From : Resent-From : ...). Would
that also mean that each one of the above "Resent-From" would have
to be present in "z" and in the right order? If not then how do you
deterimine which one was copied?
There should probably be a "bottom-up" rule for copied headers, I suspect.
The transformation of the data for copied header fields is kind of
"crude" and "messy", I can see problems if header is complex something
like DKIM-Signature for example :) My suggestion is to again look at
my proposal to just go ahead and copy the header all together and
put it as separate "Saved-XXXXX-From: ..." trace field and just
directly refer to that in the 'h' list. Plus using this sytem also
means that header field does not need to be copied every time (for
multiple MTAs in email path) and can be copied once and future
signing system can reuse and reference existing field.
By putting the copied header fields in the DKIM-Signature header field,
it is guaranteed that the copies are signed (since DKIM-Signature is
self-signed). Otherwise, a lot of new requirements about the
DKIM-Signature signing particular other header fields need to be
created, and this seems cleaner.
8. TXT record data
In section 3.7.1 it specifies separate tag "k" to specify key type
and tag "h" for hash algorithm where as in DKIM-Signature there is
one tag "a" that specifies "rsa-sha1". These differences to not make
sense - either in both cases it should be specified as "rsa-sha1" in
one tag or in both cases it should be specified with separate tag
for key type and for hash algorithm.
I agree that it's a little inconsistent now.
9. URL reference in Acknolidgements
From section E -
"The DomainKeys specification was a primary source from which this
specification has been derived. Further information about DomainKeys
is at <http://domainkeys.sourceforge.net/license/patentlicense1-1.html>"
The address above about domainkeys is "license", I doubt that is intent
as reference seems to be to genereal specification. But in any case if
you want to specify which work was primary source that should be listed
under references and not as URL in this section. I'd recommend listing
as reference existing published IETF draft though instead of URL.
This is a loose end that we weren't able to completely clean up prior to
deadline.
BTW - Previous section "D" which is prior to "E" seems to be totally
empty.
We probably will need a glossary, though.
10. References
In 10.1 under Normative references you list
[OPENSSL] Team, C&D, .., WEB http://www.openssl.org/docs/, June 2005
For of all listing URL (and without even pointing to specific document)
instead of document in normative section is considered something like
strongly not recommended. Second why is it in normative in the first
place when the only reference to openssl I can find is in examples and
examples are not part of normative text of the specification. Similarly
I would recomend checking all other normative reference to make sure
they are used in parts of the text that is normative as opposed to
additional information note or example.
I'm not even sure why the [OPENSSL] reference is there; I don't see it
referenced.
Also I do not see full draft names for ID-DK-RR ad ID-DKPOLICY, what
you have there is totally not appropriate for reference.
True; ID-DK-RR hasn't been written yet and ID-DKPOLICY is
draft-allman-dkim-ssp-00.txt which was just published.
11. IANA Considerations
a. IANA Considerations are missing registration of DKIM-Signature header
field.
b. "Use of the _domainkey prefix in DNS records will require
registration
by IANA."
Where exactly did you expect to register dns prefix? This is NOT
SRV!!!
Right, and SRV only allows the use of protocol names, so we need
something new (i.e., a new IANA registry, not just a new value).
c. "The DKK and DKP RR types must be registered by IANA."
RR Types are not registered in normal sense - IANA assigns new RR
number per requests. Also isn't it my understanding that both DKK
and DKP are going to be covered by separate drafts, why is this
IANA registration about them is here then?
Sure; this can probably move to that other draft when it is written.
12. Examples
From section B3 -
"Authentication-Status: XXX"
Where exactly is "Authentication-Status" defined?
[ID-AUTH-RES]
From section B2 -
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
I don't see "SUBMISSION" as valid value for "with" at the
http://www.iana.org/assignments/mail-parameters
and "from dsl-10.2.3.4.football.example.com [10.2.3.4]" is
also invalid syntax for Received, see RFC2821
OK; this isn't normative, but no reason it shouldn't be right.
From section 3.5 -
DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane <---- Missing
";"
c=simple; q=dns; i=(_at_)eng(_dot_)example(_dot_)net; t=1117574938;
x=1118006938;
h=from:to:subject:date;
z=From:foo(_at_)eng(_dot_)example(_dot_)net|To:joe(_at_)example(_dot_)com|
Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700
And I think another missing ";" at the end of "z" value as well.
Correct.
-Jim