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 <dcrocker(_at_)bbiw(_dot_)net>
Organization: Brandenburg InternetWorking
To: Pasi Eronen <pasi(_dot_)eronen(_at_)nokia(_dot_)com>
CC: tony+dkimov(_at_)maillennium(_dot_)att(_dot_)com
<tony+dkimov(_at_)maillennium(_dot_)att(_dot_)com>,
dkim(_at_)esiegel(_dot_)net <dkim(_at_)esiegel(_dot_)net>,
phillip(_at_)hallambaker(_dot_)com
<phillip(_at_)hallambaker(_dot_)com>,
stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>,
barryleiba(_at_)computer(_dot_)org <barryleiba(_at_)computer(_dot_)org>
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html