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

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Nov 2006 00:05:07 +0200 (EET)

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
> [email-masked] or [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: DKIM Chair <[email-masked]>
Date: Tue, 07 Nov 2006 22:31:59 -0500

> The spec seemed to be very well written and was easy to read.

On behalf of the document authors and the working group, thank you!

And Pekka, thanks so much for taking the time for a thorough and useful
review.  The document authors are working on a detailed response, and
on addressing the issues you brought up.  Expect a response soon,
copied to the DKIM mailing list and the IESG.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Tony Hansen <[email-masked]>
Date: Tue, 07 Nov 2006 22:45:47 -0500

I have various minor nits with the base document. Overall I consider the
document ready to go; these nits can be taken care of during AUTH48.

	Tony Hansen
	[email-masked]

1. Introduction

  o archival is not a design goal
    ^^^^^^^^

All of the other bullet items have full sentences, but this one does
not. (Archival is an adjective, not a noun.) Suggestions are replacing
"archival" with "message archiving" or "archiving".

3.2 Tag=Value Lists

< however, no encoding may include the semicolon (";")

This is slightly ambiguous, as it could be read as saying that the value
being encoded cannot have a semicolon in it, as opposed to the encoded
version of the value. I suggest that this be changed to read

> however, no encoding may use an unencoded semicolon (";")
or
> however, no encoding may produce an unencoded semicolon (";")

3.3.1 The rsa-sha1 Signing Algorithm
3.3.2 The rsa-sha256 Signing Algorithm

< (defined in PKCS#1
< (actually PKCS#1

This wording is different between these two sections and could lead
someone to wonder what is different in their treatment. I suggest that
they be made the same.

3.3.3 Key sizes

< See [RFC3766] for further discussion of selecting
> See [RFC3766] for further discussion on selecting

3.5 The DKIM-Signature header field

< after the body of the message;

We no longer include the body of the message in the digest calculation.
I suggest changing this fragment to:

> after the rest of the header fields being signed;

5.4 Determine the header fields to Sign

< Signers MAY claim to have signed ...
< ...
< Signers choosing to sign ....
< The signer MAY include more instances of a header field ...

The sentence "The signer MAY" is at the end of the paragraph starting
"Signers choosing". It would make more sense to move this information to
the paragraph starting "Signers MAY claim".

6.1.3 Compute the Verification

< 3. Verify that the hash of the canonicalized message body computed ...

What happens if the hash does not match? Suggested addition is:

> If the hash does not match, the verifier SHOULD ignore the signature
> and return PERMFAIL (body hash did not verify).

< used the "N-4" trick ... informative note in Section 5.5.

The informative note is really in Section 3.4.5, but is not referred to
there as 'the "N-4" trick'. The reader may have a problem following this
reference. I suggest you change it to this:

> used the "N-4" trick (omitting the final "--CRLF") ... informative
> note in Section 3.4.5.

6.2 Communicate Verification Results

< Verifiers may wish to delete existing results header fields after
< verification and before adding a new header field to circumvent this
< attack.

This sentence is a bit awkward. I suggest his instead:

> To circumvent this attack, verifiers may wish to delete existing
> results header fields after verification and before adding a new
> header field .

A.1 The user composes an email and A.2 The email is signed

The message as shown in these two sections are not identical. In
particular, the indentation before "Joe" is different in the two
examples. The A.2 and A.3 examples are consistent, so I suggest that the
example in A.1 be changed. An alternative is to provide an explicit dump
of the example in A.1 so the exact bytes are known, such as:

0000000   F   r   o   m   :       J   o   e       S   i   x   P   a   c
0000020   k       <   j   o   e   @   f   o   o   t   b   a   l   l   .
0000040   e   x   a   m   p   l   e   .   c   o   m   >  \r  \n   T   o
0000060   :       S   u   z   i   e       Q       <   s   u   z   i   e
0000100   @   s   h   o   p   p   i   n   g   .   e   x   a   m   p   l
0000120   e   .   n   e   t   >  \r  \n   S   u   b   j   e   c   t   :
0000140       I   s       d   i   n   n   e   r       r   e   a   d   y
0000160   ?  \r  \n   D   a   t   e   :       F   r   i   ,       1   1
0000200       J   u   l       2   0   0   3       2   1   :   0   0   :
0000220   3   7       -   0   7   0   0       (   P   D   T   )  \r  \n
0000240   M   e   s   s   a   g   e   -   I   D   :       <   2   0   0
0000260   3   0   7   1   2   0   4   0   0   3   7   .   4   6   3   4
0000300   1   .   5   F   8   J   @   f   o   o   t   b   a   l   l   .
0000320   e   x   a   m   p   l   e   .   c   o   m   >  \r  \n  \r  \n
0000340   H   i   .  \r  \n  \r  \n   W   e       l   o   s   t       t
0000360   h   e       g   a   m   e   .       A   r   e       y   o   u
0000400       h   u   n   g   r   y       y   e   t   ?  \r  \n  \r  \n
0000420                       J   o   e   .  \r  \n
0000433

A.2 The email is signed

The hashes in this section are not what would be produced by the sample
private key found in Appendix C. (This was discussed at one of the past
meetings.) Change bh= and b= to the following values:

bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=;

b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B7Tp1a1kEwZKdOtlTHlvF4JKg6
RZUbN5urRJoaiD4RiSbf8D6fmMHtzEn8/OHpTCcdLOJaTp8/mKz69/RpatVBas2OqWas7jrlaLGf
HdBktHs6fxOzzAB7Wro=;

A.3 The email signature is verified

< The result ... is stored in the "Authentication-Results" header
< ...
< X-Authentication-Results: shopping.example.net
<    header.from=[email-masked]; dkim=pass

These are not consistent, and imply the pre-existence of the A-R header.
Also, it is not the header.from value that has been authenticated, but
the i= value within the dkim-signature. I suggest that these lines be
changed to:

< The result ... could be stored in a header named something like
< "Dkim-Authentication-Results"
< ...
< Dkim-Authentication-Results: shopping.example.net
<    header.dkim.i=[email-masked]

---

From: Eric Allman <[email-masked]>
Date: Mon, 13 Nov 2006 13:45:43 -0800

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
<[email-masked]> wrote:

>> The IESG has received a request from the Domain Keys Identified
>> Mail WG  to consider the following document:
>>
>> 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 [email-masked] or [email-masked] mailing lists by 2006-11-07.
>

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

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.

>    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."

> ==> 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.,
> 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
> ==> 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.
>
>    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:
>

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).
>
>
> 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."

> ==> 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.

> ==> 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."

>    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

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.

>    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

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.
> ..
> ==> 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.
>

Yep, thanks.

> ==> 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.

> ==> this has been published as an RFC.

4686.  Check.

>    specification has been derived.  Further information about
> DomainKeys    is at
>
> ==> 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

---

From: Eric Allman <[email-masked]>
Date: Mon, 13 Nov 2006 13:45:43 -0800

Pekka,

Thank you.

Yep, thanks.

4686.  Check.

eric

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Nov 2006 16:17:26 +0100

On 13-Nov-2006, at 22:45, Eric Allman wrote:

> 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.

For the benefit of those who do not follow dnsext closely, what  
friction do you expect?

I wasn't holding a stopwatch, but the last RRtype assignment I saw  
striding by (the one documented in RFC 4421) seemed to be relatively  
straightforward.

Is the issue the assignment of a new RRtype, a practical  
consideration of implementation of the new RRtype in zone file  
parsers, an inability of particular implementations to handle opaque  
types, something else, or all of the above?

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Nov 2006 08:03:03 -0800

>For the benefit of those who do not follow dnsext closely, what 

As Eric stated in his message, we should not rehash old arguments. 
This has been beaten to death on the DKIM WG mailing list. As 
expected, different people had different (and, in this case, 
strongly-held) views, but consensus was reached and agreed to by the 
AD and with the DNS folks.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Nov 2006 17:13:16 +0100

On 14-Nov-2006, at 17:03, Paul Hoffman wrote:

> strongly-held) views, but consensus was reached and agreed to by  
> the AD and with the DNS folks.

Indeed, I wasn't attempting to rehash an old argument specifically  
about DKIM.

I rather thought that the general difficulties (perceived, actual, or  
otherwise) might be worth enumerating in a more general forum so that  
they are better-known. I doubt DKIM is the last work which will  
feature new types of data being stored in the DNS.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Nov 2006 10:59:25 -0800

Joe Abley wrote:
> Indeed, I wasn't attempting to rehash an old argument specifically about 
> DKIM.

Excellent. Thanks!

> they are better-known. I doubt DKIM is the last work which will feature 
> new types of data being stored in the DNS.

This is probably a topic worthy of further discussion, for exactly the reason 
you cite.  It is an issue that keeps coming up and keeps causing significant 
debate.  I do not know what it will take to put the issue fully to rest, but it 
seems clear to me that it needs a focused discussion and effort.

Possibly not on the IETF list. I don't know what the right venue is.

But most certainly not as part of the DKIM Last Call.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Hansen <[email-masked]>
Date: Tue, 14 Nov 2006 22:54:54 -0500

>        is definitely a bad strategy in this security context.

One clarification to this for Pekka, in case he missed it: Section 3.2:
Unrecognized tags MUST be ignored.

	Tony Hansen
	[email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 16 Nov 2006 16:10:53 +0100

In reply to Joe Abley, Dave Crocer wrote:
>> I rather thought that the general difficulties (perceived, actual,  
>> or otherwise) might be worth enumerating in a more general forum  
>> so that they are better-known. I doubt DKIM is the last work which  
>> will feature new types of data being stored in the DNS.
>
> This is probably a topic worthy of further discussion, for exactly  
> the reason you cite.  It is an issue that keeps coming up and keeps  
> causing significant debate.  I do not know what it will take to put  
> the issue fully to rest, but it seems clear to me that it needs a  
> focused discussion and effort.
>

See:
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-2929bis/

It is post working group last call, but not at IESG quite yet.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Nov 2006 22:37:23 -0500

> the AD and with the DNS folks.

To avoid repeating this debate, can someone post some summary  
information on this particularly including which exact people came to  
consensus about this. I'm particularly interested in if the consensus  
included the contributors to draft-iab-dns-choices since that has  
been raised in LC comments.

Thanks, Cullen

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 19 Nov 2006 19:51:08 +0100

On 19 nov 2006, at 04.37, Cullen Jennings wrote:

> information on this particularly including which exact people came  
> to consensus about this. I'm particularly interested in if the  
> consensus included the contributors to draft-iab-dns-choices since  
> that has been raised in LC comments.

The draft-iab-dns-choices document, that I am one of the editors of,  
is waiting for the draft-ietf-dnsext-2929bis document that specifies  
a more clear process (and easier) for new RR types.

I have personally told everyone that ask, including the DKIM people,  
that the best solution is to create a new triple {owner, class, type}  
as specified in the choices document, so the RRSet returned as  
response to a DNS query is containing the records one want, and as  
small number of non interesting records as possible.

My personal, most personal, view is that creation of a new RR, and  
use of a new RR, is easier than many people think.

The creation of a subdomain in the case of DKIM do make a new triple,  
and make the deployment easier, as the subdomain that the DKIM  
related data is stored in can be delegated and managed by the mail  
administrators of the main domain, while the main zone is managed by  
the DNS people. So, I think the creation of the subdomain is a good  
choice regardless of whether a new RR type is created or not. At the  
same time, that subdomain most certainly will contain non DKIM  
related data as well, for example data related to DNSSEC.

But, as you ask:

I was part of the discussion in the DKIM wg, and I do accept the  
rough consensus was to move forward with reuse of an existing RR Type  
(TXT).

Note that the draft say:

> 3.6.2.2  Resource Record Types for Key Storage
>
>    The DNS Resource Record type used is specified by an option to the
>    query-type ("q=") tag.  The only option defined in this base
>    specification is "txt", indicating the use of a TXT Resource Record
>    (RR).  A later extension of this standard may define another RR  
> type.

I do not see any need for reopening this question again. DKIM need  
this document, NOW!

But, I personally do hope someone will create a new RR Type  
definition for DKIM some day in the future.

     Patrik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Nov 2006 14:52:39 +0200 (EET)

On Mon, 13 Nov 2006, Eric Allman wrote:
> 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.

I do not believe this is an appropriate way to handle IETF LC 
comments.  This approach could be understandable for issues which have 
already been discussed at the WG (and no significant new perspective 
is brought up in the IETF LC). A pointer to an issue tracker (if any) 
might help if the issues have already been discussed..

> RFC 2119 does not require that conditions indicated by MUST, SHOULD, etc. be 
> detectable or enforceable by the receiver.

Unfortunately, it doesn't, but the specifications are still required 
to be of sufficient clarity, see e.g., draft-iesg-discuss-criteria 
section 3.1.  A MUST or SHOULD statement which is not implementable 
may fail that test.

At least right now, I don't see the point in responding to the rest of 
the response.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Nov 2006 13:01:34 +0000

Pekka Savola wrote:
>> wording issues, and (b) find show stoppers.  In several cases you have 
>> made some good suggestions, but since they fall in the grey area 
>> 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.
> 
> I do not believe this is an appropriate way to handle IETF LC comments.  
> This approach could be understandable for issues which have already been 
> discussed at the WG (and no significant new perspective is brought up in 
> the IETF LC). 

I believe that that's what he meant.

 > A pointer to an issue tracker (if any) might help if the
> issues have already been discussed..

The issue tracker for the DKIM WG is at:

https://rt.psg.com/Search/Results.html?Order=ASC&Query=%20Queue%20%3D%20'dkim'&Rows=50&OrderBy=id&Format='%20%20%20%3Cb%3E%3Ca%20href%3D%22%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__id__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3A%23'%2C%0A'%3Cb%3E%3Ca%20href%3D%22%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__Subject__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3ASubject'%2C%0A'__Status__'%2C%0A'__QueueName__'%2C%0A'__OwnerName__'%2C%0A'__Priority__'%2C%0A'__NEWLINE__'%2C%0A''%2C%0A'%3Csmall%3E__Requestors__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__CreatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__ToldRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__LastUpdatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__TimeLeft__%3C%2Fsmall%3E'

S.