2.6.9 Message Authentication Signature Standards (mass)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-14

Chair(s):

Dave Crocker <dcrocker@bbiw.net>
Jim Fenton <fenton@cisco.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

Several proposals have recently been published for the signing of
messages,primarily email messages, to deter source address spoofing. 
These include:
        DomainKeys, draft-delany-domainkeys-base-00.txt
        Identified Internet Mail, draft-fenton-identified-mail-00.txt
        E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf

While the prevention of message spoofing is also a goal of the MARID
working group, cryptographic approaches to this problem are explicitly
outside the charter of MARID.  Nevertheless, many that are familiar
with the address-based authorization approaches MARID is considering
consider them to be an interim step until message signing is deployed,
or as a complementary technology to be used along with message signing.

This BOF (and IETF Working Group formation, if there is sufficient
interest) will focus on standards for message signing, including:
- Signature format (syntax) and binding to message source dress
- Key management procedures
- Selection of message content to be signed (headers, etc.)
- Mechanisms for minimizing breakage as messages pass through the mail
  system
- Operation of message signing in concert with address-based
  authorization

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Minutes of the Message Authentication Signature Service (MASS) BoF
63th IETF, held Thursday, 4 August 2005, 1030-1230


Chairs:
Dave Crocker <dcrocker@bbiw.net>
Jim Fenton <fenton@cisco.com>


Scribe:
Eliot Lear


Jabber Log:
http://www.xmpp.org/ietf-logs/mass@ietf.xmpp.org/2005-08-04.html


1. Area Director Greeting

Russ Housley began the session by noting that considerable work has been done since the last MASS BoF, including the merger of proposals to create DKIM, which is what this session is about. Calling it the MASS BoF was probably a mistake; it should perhaps have been called the DKIM BoF. DKIM is the first of the MASS technologies to advance to have a BoF, but does not mean that it is the only such technology that will be considered by IETF. However, whatever related technology is first chartered as a working group will raise the bar for others which wish to be chartered, for interoperability's sake. One of the questions that needs to be answered is whether this is the technology that we want to raise the bar.

2. Agenda Bashing

Q: (Eric Rescorla): Will we see a threat analysis before we describe the protocol?

A: (Jim Fenton et al): There was some threat analysis in the DKIM draft, and an effort in the past three days by several of us to produce an independent threat analysis document, but otherwise no.

3. DKIM Review

Eric Allman presented a short summary of DKIM. This was not just a joint effort of Cisco and Yahoo!, but also others including Sendmail and PGP Corp. The goals are similar to those of DomainKeys and IIM, including the desire to avoid creating new trusted third parties, and to avoid client upgrades (at least at first). Naive users should not see different things they don't expect. We want to validate the message itself rather than the path. It looks a lot like DomainKeys, and key records are backward compatible with DK. The signature is slightly different, however; for example, the signature is self-signed and headers which are signed must be explicitly named. Controversial points include the non-use of S/MIME, PGP, and PEM, body length counts, the ability and scalability to issue per-user keys, and the types of canonicalization to be used.

DKIM is not seeking to be rubber-stamped by IETF; we have many issues that have been put down as a compromise and we need further input. The new DNS RRs haven't been defined yet, and we need help from the DNS community for that.

Clarifying Q&A:

Q (Pete Resnick): You said S/MIME, PGP, etc., weren't necessary; why weren't they sufficient?

A (Eric Allman): They violate the principle that naive users shouldn't see changes. If you have a mail reader that doesn't support them they can be very visible.

Q (Ted Hardie): What were your goals for affinity groups and forwarding?

A (Eric Allman): There are forwarders that modify the message and those that don't. Transparent forwarders (those that don't) should continue to work without modification; these are a problem for path-based approaches. Those that do (e.g., many mailing list exploders) will, best case, re-sign the message. Initially, some signatures will fail because this doesn't occur.

Q (Pete Resnick): If an exploder only adds headers (assuming the sender hasn't prohibited adding specific headers), will the message survive?

A (Eric Allman): Yes. Use of l= also allows can also allow the message to survive even if the exploder appends to the body.

3.1 IPR issues

The only known IPR on DKIM is held by Yahoo!. Miles Libbey of Yahoo! stated that there is a patent application around DomainKeys technology. They expect to make an IPR statement by September 9. It will be at least as lenient as that on DomainKeys. Yahoo! has also abandoned any trademark claims on the term DomainKeys; the US Patent and Trademark Office has rejected the trademark as too descriptive. This is probably a Good Thing because it should apply similarly to other claims on the term.

The DomainKeys license agreement is at http://domainkeys.sourceforge.net/license/softwarelicense1-1.html

Q (William Leibzon): Will a working group be formed prior to September 9?

A (Russ Housley): It would be impossible to form a working group that fast anyway.

4. Proposed charter:

Jim Fenton walked through the proposed charter (included in the slides). There are two drafts, draft-allman-dkim-base and draft-allman-dkim-ssp at this point; we are asking that these be used as the starting point. He also read through the charter issues raised on the mailing list (also included in the slides).

5. Open mike:

(Jim Sharp?): Need to be clear on what we mean by MTA

(Phillip Hallam-Baker via Jabber): Paragraph 2 items should be non-goals rather than out of scope. Proposal is to link to defined key retrieval meachanisms such as XKMS, not to design new ones.

(Pete Resnick): The threat analysis posted on the net isn't a threat analysis; it should address what this mechanism stops. Suggest chartering with a single threat analysis item and then rechartering.

(Russ Housley): No, because the first WG raises the bar for others, we need the threat analysis before chartering.

(Ted Hardie): Would like more discussion of the protocol to understand how hard it will be to get from input to output specs.

(Keith Moore): DKIM is a major improvement over both DK and IIM, yet chartering a working group specific to DKIM may be a disservice. The charter presumes that tweaking DKIM is an appropriate approach, but until we understand how to build an authentication system for more than phishing it might be premature. This might also be separable between apps and security.

(Doug Otis): Replay abuse is a problem; I don't consider the spec as written to be sufficient. The exclusion of reputation from the charter makes me wonder how we're going to elevate that to enough stature that it's dealt with properly.

(Jim Fenton): There is work being done on reputation and accreditation but it is separable.

(Doug Otis): To clarify, this isn't about how to hook into reputation and accreditation systems, but rather how to make the signature mechanism suitable for such use.

(Andy Newton): Need an explicit statement about DomainKeys back compatibility, and the word "core" should not be in the signature draft.

(Scott Hollenbeck): Concerned about chairs squashing discussion based on their perception of "minimal and necessary changes".

(William Leibzon): Also concerned with what "minimal" changes are, and not allowing comparisons to other solutions.. Concerned about size of public keys in DNS; IIM used fingerprints, which are considerably smaller.

(Jim Fenton): This is just a tradeoff between storing keys in DNS vs. in the message.

(Eric Rescorla): Charter can't be finished until threat analysis is done, so might be more useful to talk technical issues. Just because spam and phishing messages are almost always forged, preventing forgery doesn't prevent spam and phishing.

(Jim Fenton): As discussed before, spam and phishing are examples only.

(Eric Rescorla): Forgery protection is not important.

(Chris Newman): The charter is good enough. Don't expand work beyond what's feasible. The biggest risk is overpromising. This document is above average as an input for successful working groups.

(Keith Moore): Despite what's alluded to in the spec, message authentication won't solve spam, and neither will authentication with reputation. There is danger that we'll go off and do this and it won't solve a problem, or even make the situation worse.

(Pekka Nikander, speaking as an individual): Even if we solve a small problem and not the big problem, we may be able to use this to solve the bigger problem. We may not even understand what the problem is that this solves yet.

(Nathaniel Borenstein): Agree, and making forgery harder is still useful, even if it isn't effective against spam.

(Dave Crocker): Inclined to ask for a sense of the room as to whether DKIM is useful enough to charter a working group on it.

(Eliot Lear): The hum should be: Is DKIM the right solution to raise the bar? If so, we should work on the charter.

(Dave Crocker): There are concerns about both the charter itself and about DKIM that need to be resolved. Figuring out the utility of DKIM is significant too. Is there enough "faith" in the room that DKIM solves something useful to proceed?

(Pete Resnick): Some folks don't want to get to the charter until we answer the "why are we doing this" question. Those folks will probably answer "no" to Eliot's question at this point.

(Dave Crocker): Restating the question, starting with "Given that the preconditions are met..."

(Ted Hardie): How do we judge that the preconditions are met? On the DKIM mailing list?

(Keith Moore): Charter discussion is premature. How many people think DKIM is sufficiently useful for IETF to charter a working group to work on it?

HUM: about evenly split between "useful" and "don't know".

(Randy Gellens): Suggested goal: reduce bounces to forged mail rather than even mention spam or phishing.

(Jim Fenton): More detail on DKIM or on its applications? (more people asked for detail on its applications)

(Sam Hartman): Will it break anything?

Several people want to talk about threat analysis.

(Nathaniel Borenstein): "demonstrably useful" and "not harmful" are two very different standards. Requiring standards to be demonstrably useful would result in much smaller IETF meetings [laughter].

(Geoff Mulligan): We went to the moon without knowing what we would get. If it helps in some way, it's a good thing to do.

(Dave Crocker): Is the threat analysis just a couple of statements?

(Pete Resnick): Might be useful to describe what this does that other things don't do, e.g., this is a non-disruptive way of signing mail.

(Phillip Hallam-Baker via Jabber): It would help with forgery if the charter were changed. Unless it links to the PKIX work this won't very useful for the banks.

(Lixia Zhang): When the Internet was built, people were nice, so no defensiveness was built in. But the world has changed; DKIM adds defensiveness, and this is the sort of thing we should encourage. Nevertheless we should not oversell it.

(Dave Crocker): Homework assignment for participants: Make a simple, reasonably compelling statement that undersells the utility of this but still shows utility. Post comments at ietf-mailsig@imc.org, also see http://dkim.org

(Derek Atkins): I am Eric Rescorla, if you don't like what I'm about to say, send a bounce message to Eric Rescorla. [laughter] Just because some people don't see the utility of this doesn't mean there isn't one. Just because there is one doesn't mean this solves all problems. The key question: Is there a problem this solves that should get solved?

(Mike Thomas): RFC 822 in its current form, which allows wholesale forgery, would never pass muster these days. At some level this is to patch holes in that protocol that nobody thought about 25 years ago. That should satisfy the utility concerns.

(Keith Moore): A lot of people want to do something about spam, phishing, viruses. We would rather trust gut instinct than analysis. We shouldn't just downgrade our stated goals (wink, wink) to get them through process. Do we believe this will help with each of these things? Do we believe this is a significant improvement over S/MIME and OpenPGP?

(Dave Crocker): Should we revector to a new, DKIM-specific, mailing list? [Consensus that we should].

(Scott Rosco): Will this break anything? If not, and there is a reasonable probability that this will reduce spam even 20%, then please go ahead.

(Arvel Hathcock): It seems on its face to be useful to know who you're communicating with. Otherwise, go home and tape over the peepholes on your front doors.

(Chris Newman): Email was designed as a reliable store-and-forward message system; bounces come back if there is a failure. Today there are so many bounces that bounces get ignored, and it isn't reliable any more. This needs to be fixed, and DKIM, along with some policies can help.

(Doug Otis): DKIM's goals should be to establish accountable domains, and not authors. It isn't suitable for preventing the bounce problem. DKIM can be useful if we provide enough of the normal protections in a signature scheme. I don't see that yet.

(Eric Rescorla): I have heard a bunch of justifications. I agree with Keith that we need to sit down and agree on realistically does and doesn't do.

(Barry Leiba): The goal here isn't to stop spam, but to reduce the ability to spoof the sender address. It gives a domain a way to take responsibility for mail. So the question is really: If it stops spoofing, why is that useful? We need to focus on that.

6. Next steps (Dave Crocker)

DKIM mailing list will be quickly set up, address will be posted on http://dkim.org and on the ietf-mailsig@imc.org mailing list. We should focus on questions of threat analysis and utility there.

Slides

MASS / DKIM BOF
DKIM Overview