Subject: [secdir] FW: Secdir review of draft-ietf-dkim-deployment-11.txt

From: Charlie Kaufman <[email-masked]>
Date: Mon, 1 Feb 2010 23:42:38 +0000

I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.

This is a re-review, and nothing in the document has changed that would affect my review. All of my comments were in the form of questions for which it would be helpful to include answers in the document if the authors knew them. I'm guessing they didn't.

Attached is my old review of -10.

	--Charlie

-----Original Message-----
From: Charlie Kaufman 
Sent: Friday, December 18, 2009 10:38 PM
To: [email-masked]'; [email-masked]; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Secdir review of draft-ietf-dkim-deployment-10.txt

I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.

This document covers development, deployment, operations, and migration considerations for DKIM (DomainKeys Identified Mail). I would expect such a document to give guidance to implementers and deployers of this technology that couldn't be included in the standards track documents because the standards wanted to allow flexibility to implementers and deployers. Such guidance would be particularly useful with DKIM because it's not at all obvious how to use it from the specs and if everyone makes those decisions independently it will limit the usefulness to everyone.

Unfortunately, it appears that there hasn't been enough real world experience with DKIM yet to provide a lot of useful guidance. This document seems more of a tutorial on DKIM than guidance. I have no problems with the guidance it gives (other than it mostly duplicates the contents of other specs), but there is a lot more that it would be good to have (assuming anyone has answers).

Specific suggestions:

In Section 7.3, the document mentions problems likely to be introduced if Author Domain Signing Practices (ADSP) is enabled. There are common practices in mail processing that will cause email to be dropped if these practices are followed, and it would be useful to have an explicit list of things known to fail and their prevalence. For example, mailing list expanders (like the ones that got this message to most of you) are likely to break the DKIM signatures on messages they pass, causing those messages to subsequently be dropped by receiving agents if the sender has enabled ADSP. It would be good to know which of the common mail forwarders have this problem and give advice to the authors of mail forwarders as to how to avoid problems in the future. The most general solution is for the forwarder to change the "From: " field in the email message to itself and copy the name of the actual sender somewhere else. But that causes other problems. Similarly, there have been in the past many web sites that let you "mail a copy of this document to a friend" and let you specify the friend's email address and your own. ADSP would delete such mail sent by users who used such a web site if the site forged the "From:" field. I've noticed that practice is decreasing (Dilbert.com doesn't do it anymore). Guidance to web sites not to do that and to users about how much trouble to expect would be useful.

DKIM allows the signer to choose which header fields in the message are signed. Guidance on which fields should be signed and which should not would be helpful.

When rolling over keys, it's a matter of sender policy how long the old signing key should remain valid for verification after it is no longer used for signing. It would be good to hear a recommendation as to how long that should be. This would be coupled with guidance to verifiers as to how long after email is received it should be expected to be verifiable. Is it reasonable to wait until logs in and reads mail, or must it be checked as part of placing the mail in the user's inbox? Do we expect to change keys every few hours or every few years?

It probably belonged in the original DKIM spec, but it would be good to know how DKIM is supposed to interact with S/MIME or OpenPGP.

It appears DKIM allows the signing of only the first 'n' bytes of a message in order to give better performance. Advice and rationale for picking an 'n' would be helpful.

On page 8, quoting RFC5672 on the issue of interpretation of the d= and i= fields, this document says "To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM's specification and semantics." While true, the purpose of those fields is so that the receiver can intuit something from them. While DKIM may not specify the semantics to allow implementers flexibility, this document should suggest possibilities and report on existing practice (if any).

Another area where guidance would be useful is in what a receiving agent should display to users concerning DKIM signed messages. Perhaps the answer is *nothing*, where DKIM is only used as one of many heuristics for spam filtering. But either way, it would be good to know. If we expect users to configure some signers as good, advice as to how they are expected to learn what to do would also be helpful.

Section 8.4 begins "It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service". Section 8.5 begins "The DKIM specification is expected to be used primarily between Boundary MTAs...". I don't believe these can both be true. I'm more inclined to believe the latter because within an organization the organization can just filter email coming from the Internet and making sure the return address is not within the organization.

	--Charlie

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 01 Feb 2010 21:31:49 -0800

On 2/1/2010 3:42 PM, Charlie Kaufman wrote:
> All of my comments were in the form of questions for which
> it would be helpful to include answers in the document if the authors knew
> them. I'm guessing they didn't.

Charlie,

I wrote a response at the time of your review, but it apparently only went to a 
small circle of folk, which was not intentional.

(The usual disclaimer applies:  the enclosed represents my personal opinion, only.)

Here's what I sent:

-------- Original Message --------
Subject: Re: Secdir review of draft-ietf-dkim-deployment-10.txt
Date: Sat, 19 Dec 2009 12:33:56 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Pasi Eronen <[email-masked]>
CC: [email-masked] <[email-masked]>, 
[email-masked] <[email-masked]>, [email-masked] 
<[email-masked]>,  [email-masked] 
<[email-masked]>, [email-masked] <[email-masked]>

Responses to the additional review -- as before, this is on my own initiative;
the other authors might have differing assessments.

Overall comment:  The issues raised are all reasonable, but they seek more
detail that is currently available.  The intent for this initial version of the
Deployment document was to provide basic information about deployment, and
revise the document as more field experience is gained.  As such, efforts to
provide increasingly broad and fine-grained information is not currently likely
to be productive.

This is the sort of exercise in which the classic "perfect is the enemy of
good" concern applies.

I did not identify any changes to the draft that are needed as a result of this
review.

d/

On 12/18/2009 10:38 PM, Charlie Kaufman wrote:
>   I have no problems with the guidance it gives
...

> Specific suggestions:
>
> In Section 7.3, the document mentions problems likely to be introduced if
> Author Domain Signing Practices (ADSP) is enabled. There are common practices
> in mail processing that will cause email to be dropped if these practices are
> followed, and it would be useful to have an explicit list of things known to
> fail and their prevalence.

1. The document points to discussion in the ADSP specification.

2. ADSP remains controversial and the decision for the Deployment document was
to make generic reference to ADSP, but not to get bogged down in the controversy.

3. The existing Deployment draft warns a potential ADSP user to be careful.
For now, that is the best and most complete advice to give.

>    The
> most general solution is for the forwarder to change the "From: " field in

Changing the From: field is a particularly onerous suggestion.  It modifies
purported authorship and it has no empirical basis for claiming improved
functional utility, safety or human usability.  It is a reasonable theoretical
suggestion but almost certainly a counter-productive one to implement.

It does, however, nicely demonstrate why ADSP is controversial.  But, again,
the Deployment document sought to give a basic acknowledgment that ADSP
exists, but to refrain from engaging in its controversy.

> the email message to itself and copy the name of the actual sender somewhere
> else. But that causes other problems. Similarly, there have been in the past
> many web sites that let you "mail a copy of this document to a friend" and
> let you specify the friend's email address and your own. ADSP would delete
> such mail sent by users who used such a web site if the site forged the
> "From:" field.

Yes it would.

> DKIM allows the signer to choose which header fields in the message are
> signed. Guidance on which fields should be signed and which should not would
> be helpful.

Yes it would.

Section 5.4 of RFC 5617 specifies this, and there is no additional guidance
available.  The community has not had discussion or formulated consensus about
it.  So the Deployment document cannot currently add to that discussion.

My personal view is that the choice matters far less than is often believed,
because data integrity -- nevermind data validity -- are not goals of DKIM.
Rather, the hashing is meant to validate the d= identifier.  Any data integrity
benefits are strictly secondary.  Hence the choice of header fields to cover is
probably quite flexible.

> When rolling over keys, it's a matter of sender policy how long the old
> signing key should remain valid for verification after it is no longer used
> for signing. It would be good to hear a recommendation as to how long that
> should be.

While that seems a reasonable idea, it would almost certainly be
counterproductive to include now, since real recommendations need to come from
some operational consensus.  Since DKIM's use of signing technology carries a
very different semantic than previous uses, and since it applies to transport
rather than longer-term, any current recommendation for key management rollover
would be theoretical rather than empirical.  The decision was to avoid having
the document engage in such abstract exercises.

> This would be coupled with guidance to verifiers as to how long
> after email is received it should be expected to be verifiable.

Either the public key is in the DNS or it isn't.  This is a transport-related
service.  There is no expectation that keys will be valid for very long.

>      Is it
> reasonable to wait until logs in and reads mail, or must it be checked as
> part of placing the mail in the user's inbox? Do we expect to change keys
> every few hours or every few years?

Again, this is a transport-related service, not one intended to be relevant to
end-users.

> It probably belonged in the original DKIM spec, but it would be good to know
> how DKIM is supposed to interact with S/MIME or OpenPGP.

Since DKIM has nothing to do with S/MIME or OpenPGP there is no "interaction".

However, the DKIM Overview (RFC 5585) contains some brief reference to these
technologies.

> It appears DKIM allows the signing of only the first 'n' bytes of a message
> in order to give better performance. Advice and rationale for picking an 'n'
> would be helpful.

l= is not for "better performance" but for robustness in the face of very
specific body changes by intermediaries -- adding text at the end.

l= is another controversial topic for which there is no additional, empirical
information available.  Again, the decision was to have the Deployment refrain
from engaging in controversy.

> On page 8, quoting RFC5672 on the issue of interpretation of the d= and i=
> fields, this document says "To the extent that a receiver attempts to intuit
> any structured semantics for either of the identifiers, this is a heuristic
> function that is outside the scope of DKIM's specification and semantics."
> While true, the purpose of those fields is so that the receiver can intuit
> something from them.

Not really.  It is so that the receiver can take those exact and complete
strings and use them for lookups into information bases.  The d= is for use in
key retrieval and reputation lookup.  The i= is for an unspecified range of uses.

In any event, the cited text seeks to warn the receiver off from parsing the
details of either string, or at least to help the receiver to understand that
any attempt to parse the strings moves the receiver beyond the scope of the
DKIM specification.

>    While DKIM may not specify the semantics to allow
> implementers flexibility, this document should suggest possibilities and
> report on existing practice (if any).

No it shouldn't.  That moves the document into heuristics that are beyond the
scope of the DKIM specification.

> Another area where guidance would be useful is in what a receiving agent
> should display to users concerning DKIM signed messages. Perhaps the answer
> is *nothing*, where DKIM is only used as one of many heuristics for spam
> filtering. But either way, it would be good to know. If we expect users to
> configure some signers as good, advice as to how they are expected to learn
> what to do would also be helpful.

"Good to know" is the problem.  There is no empirical basis for "knowing" what
to recommend.  Basically, DKIM is not for end-user display.  The associated
identifier is for processing by an assessment (and filtering) engine.

Appendix D of the DKIM core specification contains some pro forma discussion of
the topic.  The Deployment document seeks not to replicate discussion contained
elsewhere.

> Section 8.4 begins "It is expected that the most common venue for a DKIM
> implementation will be within the infrastructure of an organization's email
> service". Section 8.5 begins "The DKIM specification is expected to be used
> primarily between Boundary MTAs...". I don't believe these can both be true.

Boundary MTAs are part of an organization's email service infrastructure.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net