Re: Last Call: 'DomainKeys Identified Mail (DKIM) Signatures' to Proposed Standard (draft-ietf-dkim-base)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxx or ietf@xxxxxxxx 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


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]