On 2/9/2010 3:30 PM, Barry Leiba wrote:
Leaving the DKIM mailing list off of this for now; we can forward it
there if we need to.
We need to, so I've added the list back.
On Thu, Feb 4, 2010 at 13:02, Tim Polk<tim(_dot_)polk(_at_)nist(_dot_)gov>
wrote:
Discuss:
[Moved from discuss-discuss to a "real" discuss based on the call...]
Charlie Kaufman noted a number of open issues in his secdir review; the
authors' response was
generally "we don't have those answers yet so we need to be silent". I
agree that these issues
need not be resolved before publication, but I do think this document would
be improved by
listing these open issues. I believe there could be harm in not
communicating some of these
open issues to readers.
Tim, I appreciate the point you're making. Let me note that the
working group is about to recharter to work on advancing the base DKIM
spec along the standards process, and the work items that will be in
the new charter are these:
1. Progress DKIM base to Draft Standard.
2. Collect data on deployment and effectiveness of DKIM base.
3. Collect data on deployment and effectiveness of ADSP, and consider
the future of ADSP.
4. Update the Overview and Deployment/Operations documents, as new
data are collected.
5. Consider mailing list issues that are not already covered in the
informational documents, and include those issues in the updates,
and/or create a separate document for mailing-list managers.
Items 2 thru 5 are specifically meant to address the sorts of
questions that Charlie asked in his review, and it was always the
intent that the two informational documents (RFC 5585 and the draft at
hand) be living documents, updated periodically as more/better advice
is available.
While of course the re-chartering is true, the issue is a current, blocked
document.
That said, and as Dave says, we're happy to include a list of
questions we aim to answer in the future (in a "Future Updates" or
"Open Questions" or "Issues for Research" section), but we need to
know what items you'd like to see there, in addition to what the
working group would.
Except that this ignores the core point about including such a list in this
particular kind of document. Telling OA&M folk that there are lots of open
issues is a good way of telling them to wait to use the work until it is more
"complete".
The key point, here, is that a list of open issues is quite important for a
group doing development, and is actually a distraction for operations folk.
One item is clearly "more data and advice for mailing-list managers."
That that's already an item in the new charter proposal (which Pasi
should get within the next couple of weeks, once the WG is happy with
the text) shows that the WG plans to address that.
Looking at Charlie's questions, in particular:
Charlie's questions received a detailed response, in December, and was copied
to
the DKIM mailing list:
<http://mipassoc.org/pipermail/ietf-dkim>
It concluded that no changes were needed to the draft. There were no
objections
raised to that conclusion in December or in February.
However, some of your response, below, appears to invite changes.
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 pa st 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.
This boils down to a combination of "mailing list issues" and "how use
of ADSP's dkim=discardable option will affect email-based services in
use today." [I'll point out that saying "if ADSP is enabled" is
misleading here; the issue is particularly with the use of that ADSP
option, not with ADSP in general.] New charter items 3 and 5 are
specifically meant to fill in any gaps here.
We can give speculative advice on this now, and there is, indeed, some
of that already in the document. What we need to know in order to be
clearer about what will happen in practice, is how ADSP will wind up
being used -- in practice. Will dkim=discardable be used seldom, or
often? Will verifiers wind up violating the specs and incorrectly
treating dkim=all as dkim=discardable? It would be odd to ask us to
speculate that the specifications will be violated, I think.
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.
Should we have more guidance than is in DKIM base (RFC 4871) section 5.4 ?
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's certainly reasonable for us to say something about this, but, as
you know, key management policies vary greatly, and the best we can do
is say things like "some sites may choose to change keys monthly,
others annually, and still others never." Is there much value in
that?
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's not; it's entirely orthogonal to those. They serve different
purposes. We can certainly add a paragraph somewhere to that effect,
though I'd suggest that, as Charlie says, that go into the RFC4871bis
document (item 1 in the new charter).
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.
It's not a performance issue. The "l=" parameter was meant to allow
mailing-list goop to be appended without having it invalidate the
signature. The wisdom of its inclusion is uncertain; there are those
who don't use it, and those who would like to deprecate it. We do
need more experience with it to know whether to do that, but, in
general, "n" should be the size of the message as sent.
Do you think we need anything more than what's said in the definition
of "l=" in RFC 4871 (the bottom of page 21, and the informative note
at the top of page 22)?
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).
The problem here is that the working group has had a great deal of
disagreement on this very point. We can't give suggestions until we
have more experience with deployment. And when we do have more data,
here, you can bet it'll go into a revision of the deployment
document... particularly *because* of the disagreement we've seen up
to now.
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.
This is an interesting point, because we're so often told that the
IETF doesn't do UI issues. We expect the results of DKIM tests to be
considered in spam filters in some manner, to be used to enable
reputation checks, to be used in end-user interfaces, and so on. But
that really *is* all beyond the scope of DKIM, even at the deployment
level. You get a bit of information: this message does/does not have
a valid signature on behalf of domain "example.com".
I think it would be reasonable for someone (perhaps the DKIM working
group) to do an informational or BCP document that discusses some of
the things people are using the information for. We need to find out
more about what people use the information for, in order to do that.
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.
I think Charlie misunderstood this statement. It means to say that
it's more likely that an organization's boundary MTA, or some other
server within the organization's mail infrastructure, will do the
signing and verifying... rather than having it done by the user's MUA,
for example.
Suggestions for alternative text here would be helpful, if you really
think what's there is unclear (after reading the whole section, not
just the one sentence).
Barry
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html