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

[Eric Allman]

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.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.org or ietf at ietf.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