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]

 



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.

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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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