On Mon, 11 Jul 2005, Tony Hansen wrote:
What's on http://mipassoc.org/mass *is* what was sent to the I-D editor.
There's *always* room for improvement and we know it's not perfect.
Well ok. I'm going to go first mostly though errors & omissions (most are
fairly easy to fix for next draft), more fundamental suggestions that have
to do with architecture or with some inappropriate marketing text in the
beginning of the draft is going to be in separate post.
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".
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.
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.
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.
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.
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
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
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.
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"
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?
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.
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.
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.
BTW - Previous section "D" which is prior to "E" seems to be totally empty.
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.
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.
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!!!
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?
12. Examples
From section B3 -
"Authentication-Status: XXX"
Where exactly is "Authentication-Status" defined?
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
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.
-----------------------
Ok, I need to go eat some breakfast before I can write more. There
are more problems in there and in particular I need to go through
canonicalization in more detail and compare to my draft and testing
I've done on this.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/