On Tue, 24 Oct 2006, The IESG wrote:
The IESG has received a request from the Domain Keys Identified Mail WG
to consider the following document:
- 'DomainKeys Identified Mail (DKIM) Signatures '
<draft-ietf-dkim-base-06.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by
2006-11-07.
The spec seemed to be very well written and was easy to read.
As a meta-comment, I'd rather have seen a new RR type used instead of
TXT (I believe the DKIM participants can live with the issues
deploying a new RR type causes) but as it's put in a sub-domain, it
should hopefully have only minimal impact on non-DKIM use of TXT
record.
I have some issues with the spec, many of which are detailed but a
couple also a bit higher level. These are described at more length
below under "substantial issues". I expect all of these should be
relatively easily resolvable. I'd summarize these as:
1) A couple of times a MUST/SHOULD statement doesn't seem to be
implementable. Either this is meant as operational guidance (and
shouldn't use upper caps and should be otherwise reworded) or the
implementation requirement should be clarified.
2) It is not very clearly specified what verifiers should do if a
number of "MUST/MUST NOT" specifications fail that check. This
seems unspecified.
3) DKIM imposes additional requirement to RFC2822 implementations
about (no) header reordering (otherwise DKIM signatures don't
verify) that is not spelled out clearly enough.
4) There seems to be slight mismatch wrt wording in different places
what DKIM may do with unverifiable mail. (And it's not clear what
"unverifiable" here means). Similar lack of clarity exists what
exactly 'signature verification failures' means in the context of
"signature verification failures MUST NOT return 4xx SMTP
replies".
5) d= tag must be the same or a parent domain of domain part of i= tag,
but has 'parent domain of domain part' been defined? (consider e.g.,
foo.example.com wrt foo.example.command.com or foo.example.com.bar.com.
6) Security considerations is a bit weak; analysis against the DKIM
threats document doesn't exist (though I'm not sure if it should),
countermeasures to a few attacks haven't been mentioned (or
spelled out that those don't exist), especially potential harm of
DKIM to non-DKIM 3rd parties (e.g., DNS 'reflection-like' attacks
against DNS authoritative servers) isn't described, DNSSEC is
expected the solve the public key rendezvous problems, but no
standards track solution for the forward zone can expect global
deployment any time soon.
substantial
-----------
Reusing a Selector with a new key (for example, changing the key
associated with a user's name) makes it impossible to tell the
difference between a message that didn't verify because the key is no
longer valid versus a message that is actually forged. Signers
SHOULD NOT change the key associated with a Selector. When creating
a new key, signers SHOULD associate it with a new Selector.
==> it seems like 'Signer' here refers to a postmaster or whoever is in
charge of selecting Selectors. Are these SHOULD conditions/enforcement
implementable, if so, how? If this is purely operational guidance, I would
phrase it differently, without uppercase, such as 'Administrators should
not change the key associated with a Selector...' On the other hand, if
this is meant as an implementation specification, maybe some rewording might
make it clearer how to implement it.
Tags with duplicate names MUST NOT be specified within a single tag-
list.
==> what does this 'be specified' mean? That if you encounter the same
tag-name twice under a tag-list, you should discard it? If so, why not specify
that?
This value MUST NOT be
larger than the actual number of octets in the canonicalized
message body.
...
The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
...
[dozens of other similar specifications.]
==> what is the expected verifier's behaviour if one or more of these
MUST/MUST NOTs doesn't hold? AFAICS, that hasn't been specified, at least
not very clearly. Should it be?
Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be
used. Note also that wildcards within domains (e.g.,
s._domainkey.*.example.com) are not supported by the DNS.
==> This MUST NOT doesn't appear to be implementable, as the DKIM
implementation cannot know whether the administrator has configured
wildcards in the DNS zone or not. I'd suggest rewording for clarity, e.g.,,
"Administrators must not configure wildcard DNS records in DNS zones".
The DKIM-Signature header field is always implicitly signed and MUST
NOT be included in the h= tag except to indicate that other
preexisting signatures are also signed.
==> It might be possible to implement parts of this (e.g., disallow h= tags
if the message doesn't have pre-existing DKIM-signature header lines), but
it's not clear whether that is intended. This seems more like operational
advice which should probably be reworded.
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits
header fields to be reordered (with the exception of Received
header fields), reordering of signed header fields with multiple
instances by intermediate MTAs will cause DKIM signatures to be
broken; such anti-social behavior should be avoided.
==> this seems like an additional requirement for RFC2822 implementations so
that they will work with DKIM. Instead of an informative admonition, these
kind of additional requirements for other specification implementation
should probably be high-lighted in a much more visible part of the spec, for
example, a subsection of Introduction ('Requirements for RFC 2822
Implementations used to transit DKIM-signed Messages').
Section 6:
A verifying MTA MAY implement a policy with respect to unverifiable
mail, regardless of whether or not it applies the verification header
field to signed messages.
==> This seems to be somewhat at odds with Section 1.2:
... DKIM seeks to preserve the positive aspects of
the current email infrastructure, such as the ability for anyone to
communicate with anyone else without introduction.
and Section 1:
o signature verification failure does not result in rejection of the
message;
and:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
....
Verifiers MUST confirm that the domain specified in the "d=" tag is
the same as or a parent domain of the domain part of the "i=" tag.
If not, the DKIM-Signature header field MUST be ignored and the
verifier should return PERMFAIL (domain mismatch).
==> if the domain part of i= tag was "foo.example.com" and d= was
1) "foo.example.command.com", or 2) "foo.example.com.test.com", would the
confirmation succeed or fail? I.e., is there a precise definition of what
"parent domain of a domain part" is?
A temporary failure of the key server or other external service is
the only condition that should use a 4xx SMTP reply code. In
particular, signature verification failures MUST NOT return 4xx SMTP
replies.
==> is this MUST NOT overly restrictive? For example, if verifier's memory
runs out for the moment or it needs to create a temporary file (but disk
is full), wouldn't these be cases where a temp fail might be warranted?
Above seems to refer to succesfully completed signature verification where
the result was a failed signature which is subtly more specific than the
current wording?
8. Security Considerations
==> what I'd like to have seen is a table which evaluates the threats
mentioned in the DKIM threats doc against this protocol ("check-list").
I wonder if something like that would be done in a future document?
8.1 Misuse of Body Length Limits ("l=" Tag)
==> this section does not mention or refer to any countermeasures for these
attacks; it should.
A second security issue related to the DNS revolves around the
increased DNS traffic as a consequence of fetching Selector-based
data as well as fetching signing domain policy. Widespread
deployment of DKIM will result in a significant increase in DNS
queries to the claimed signing domain. In the case of forgeries on a
large scale, DNS servers could see a substantial increase in queries.
==> I don't think Security Considers answers very well the question, "what
harm could DKIM bring to those sites which do not participate in the DKIM
use?" Above is probably one of the biggest concerns -- emphasis on the word
_claimed_ in the last sentence. With the advent of significantly sized
records, I suspect these will end up being used to load authoritative DNS
servers much in the same manner as reflection DNS attacks were reported
earlier. And there isn't much that can be done about it. This section
certainly doesn't describe counter-measures.
...
Section 3.6 said:
However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply
having the verifier query the purported signer's DNS entry (or some
security-equivalent) in order to retrieve the public key.
==> I find it a bit strange that this security assumption was not discussed
in the security considerations. Certainly, there is a reference to DNSSEC,
but it is not clear what is the threat without DNSSEC given that
standards-track DNSSEC deployment (I'll exclude DLV for now) for this
purpose (forward zones) is likely not going to happen any time soon.
more editorial
--------------
==> According to ID-nits, a couple of lines went beyond 72 chars
2.5 Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive. However, all tokens having
names beginning with "obs-" should be excluded from this import, as
they have been obsoleted and are expected to go away in future
editions of those RFCs.
..
The following tokens are imported from [RFC2821]:
The following definitions are imported from [RFC2822]:
The following tokens are imported from [RFC2045]:
==> but you don't specify below any obs- tokens -- so why mention it here at
all ?
==> 2 of the lists use 'tokens', one 'definitions'. Is this intentional?
(probably a stupid question... :-)
1. White space in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoded of CR or LF characters that are part of a
CRLF line break.
INFORMATIVE NOTE: The x= tag is not intended as an anti-
replay defense.
==> this note would be more valuable if it also mentioned what the x= tag
was intended for, not just what it isn't.
==> s/encoded/encoding/ or something similar?
4. If the query for the public key returns multiple key records, the
verifier may choose one of the key records or may cycle through
the key records performing the remainder of these steps on each
record at the discretion of the implementer. The order of the
key records is unspecified. If the verifier chooses to cycle
through the key records, then the "return with ..." wording in
the remainder of this section means "try the next key record, if
any; if none, return to try another signature in the usual way."
==> s/return with/return/ ? -- AFAICS, 'return with' isn't used but 'return'
is.
[ID-DKIM-THREATS]
Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-fenton-dkim-threats-02
(work in progress), April 2006.
==> this has been published as an RFC.
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>.
==> this domain no longer even exists, and even if it did, referring to a
file named 'patentlicence1-1.html' should raise some eyebrows considering
the IPR rules that no claims should be referred to in the document itself.
Is this information available somewhere else? Should it be referred to
using an Informative Reference?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf