Pekka,
Thanks for your good comments, which I will try to answer as best as
I can.
Advice from our AD and WG Chairs was that in Last Call the point is
not to continue Working Group deliberations, but to (a) find minor
wording issues, and (b) find show stoppers. In several cases you
have made some good suggestions, but since they fall in the grey area
between trivial and critical we are going to have to side-step them
for now. We apologize for this, and wish we had gotten them before
we went into Last Call, but we are also trying to get the document
out sooner rather than later, and no project ever gets to the point
where all parties consider it perfect.
Several of your comments refer to normative language, e.g., you
suggest that some of the SHOULDs ought to be MUSTs. Nearly all of
these have had substantial working group review. Also, we are trying
to strictly interpret these words as described in RFC2119, which
includes:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
Working group consensus was that we couldn't dictate how the verifier
would interpret signatures, and hence we only used MUST where
absolutely necessary, and especially not where it is a matter of
verifier policy.
--On November 8, 2006 12:05:07 AM +0200 Pekka Savola
<pekkas(_at_)netcore(_dot_)fi> wrote:
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.
Thank you.
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.
By putting the record in a subdomain we believe we have avoided the
major issues associated with TXT records. I would not be surprised
if someone proposes a new RR; if so we'll deal with that as the time
comes. It just didn't seem necessary to add the friction associated
with a new RR in order to get a reliable DKIM specified.
...
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.
Although not strictly required for interoperability, changing
selectors when changing keys will be important to avoid ambiguities.
We didn't list this as a MUST because, strictly speaking, it isn't
required, even though it is a Good Idea. However, we felt that it
should be stronger than simply operational advice. Naturally this
can be debated, but after discussion among the authors we believe
that this falls into the grey area that is neither trivial nor
critical.
RFC 2119 does not require that conditions indicated by MUST, SHOULD,
etc. be detectable or enforceable by the receiver.
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?
I'm not sure I know how to word "be specified" more clearly. I've
changed this to "Tags with duplicate names MUST NOT occur within a
single tag-list; if a tag name does occur more than once, the entire
tag-list is invalid."
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?
This is already covered in (e.g.) 6.1.1:
Implementers MUST meticulously validate the format and values
in the DKIM-Signature header field; any inconsistency or
unexpected values MUST cause the header field to be
completely ignored and the verifier to return PERMFAIL
(signature syntax error). Being "liberal in what you accept"
is definitely a bad strategy in this security context.
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".
RFC 2119 does not require that the verifier be able to check that the
signer has done the right thing. However, in looking over this again
it doesn't seem to cause any actual interoperability problems, so
this should not be normative. We've reworded that to:
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
*.bar._domainkey.example.com) do not make sense in this
context and should not be used. Note also that wildcards
within domains (e.g., s._domainkey.*.example.com) are not
supported by the DNS.
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.
I guess I'm not understanding what you are saying here. The idea is
that a signer that is signing a message for the second time (e.g., a
mailing list exploder) can sign an existing DKIM-Signature header by
specifying it in h=, but no signer should ever include its own
DKIM-Signature header in the h= list. The general feeling among the
authors is that the current wording makes sense, but if you would
like to propose specific wording we could take a look at it.
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').
It's not actually an additional constraint on 2822. However, it is
an indication to signers that signing repeated header fields might
cause verification problems. Fortunately, repeated fields are fairly
rare, and most modern MTAs do not reorder in practice.
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;
....
We don't see that as conflicting. A verifier policy could be
anything, including doing existing spam scanning on unverifiable
messages, perhaps with the sensitivity turned way up, or
quarantining, or whatever.
We had a pretty basic philosophy while writing this document: we
can't tell verifiers what they have to do above and beyond the actual
mechanics of how to verify the signature. That's at least in part
because we realize that it doesn't matter what we tell them ---
they'll do what works for them anyway.
I tried to clarify the language in Section 1 using "signature
verification failure does not force rejection of the message."
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?
The term "parent domain" is well understood to be the inverse of a
subdomain. For example, it is used that way in RFC 1034.
To answer your question, neither of the examples you give would be
legal, since both would allow one domain to claim an identity
controlled by another entity.
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?
I reworded this to "Temporary failures such as inability to access
the key server or other external service are the only conditions that
SHOULD use a 4xx SMTP reply code. In particular, cryptographic
signature verification failures MUST NOT return 4xx SMTP replies."
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?
The threats document is informational rather than normative; in
particular, it's not a requirements document. Our Security Area
Director reviewed the -base Security Considerations and found it
acceptable.
8.1 Misuse of Body Length Limits ("l=" Tag)
==> this section does not mention or refer to any countermeasures
for these attacks; it should.
From section 3.5: "To avoid this attack, signers should be extremely
wary of using this tag, and verifiers might wish to ignore the tag or
remove text that appears after the specified content length."
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.
This isn't a new problem, just another way of launching an existing
attack. For example, pretty much every MTA will look up the domain
in a "MAIL FROM:" SMTP command; since that can be anything, you get
the same effect. It might be slightly worse with DKIM since the
attacker could use random selectors and thereby guarantee that local
caching could not help, but simply sending bogus messages to a large
number of unrelated domains will create the same traffic.
We would argue that this is a general DNS problem. There are lots of
ways to hammer on DNS sites, and the problem should be resolved for
the general case, not protocol-at-a-time.
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.
I'm not seeing how this is relevant for Security Considerations. This
is merely a justification for why you don't need TTP-signed certs.
About all we could say under Security Considerations is "this is not
a security consideration." Am I missing something?
more editorial
--------------
==> According to ID-nits, a couple of lines went beyond 72 chars
Damn, I thought I had gotten them all. Fixed.
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 ?
Hmm... you appear to be correct. In previous drafts we had imported
some tokens that in turn included obs-* tokens, but there appear to
be none left. Good catch.
==> 2 of the lists use 'tokens', one 'definitions'. Is this
intentional? (probably a stupid question... :-)
Not intentional. I'll clean that up.
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.
==> s/encoded/encoding/ or something similar?
Yep, thanks.
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.
There was consensus that this was a good way for the signer to
express that it wanted to limit interpretation of the signature.
Frankly I don't recall the exact rationale, but we do go with WG
consensus.
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.
Yep, that's left over from some prior wording.
[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.
4686. Check.
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?
Yes, it turns out an informative RFC on DK will come out as an RFC.
We'll just reference that.
Thanks for your great comments!
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html