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<[email protected]> 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
