Barry,
This is very good, and entirely acceptable IMO. I have a few
suggestions for what they're worth; take them or leave them as you please.
Barry Leiba wrote:
---------------------------------------------------------------------
DRAFT IETF WORKING GROUP CHARTER
8 Nov 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <housley(_at_)vigilsec(_dot_)com>
MAILING LISTS:
General Discussion: ietf-dkim(_at_)mipassoc(_dot_)org
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/
DESCRIPTION OF WORKING GROUP:
The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes
legitimate
reasons for doing this, it has become a source of general confusion,
as well
as a mechanism for fraud and for distribution of spam (when done
illegitimately, it's called "spoofing"). The DKIM working group will
The parenthetical seems to be a bit misplaced, and might fit better to
the use of the word "legitimate". This might read more easily if broken
into two sentences.
produce standards-track specifications that allow a domain to take
responsibility, using digital signatures, for having taken part in the
transmission of an email message and to publish "policy" information
about
how it applies those signatures. Taken together, these will
assist receiving domains in detecting (or ruling out) certain forms of
spoofing as it pertains to the signing domain.
Detection of spoofing is indirect at best; I'd prefer that we emphasize
the ability of DKIM to rule out spoofing.
I really like your suggestion in
http://mipassoc.org/pipermail/ietf-dkim/2005q4/001359.html that we move
away from the word "policy" and use "declaration". Should we do that
here as well? I have one concern about this: we still need to discuss
what the SSP/SSD/SSx says, and whether it would include something to the
effect, "Please deal harshly with messages that don't conform with this
declaration" or "Please don't take this declaration very seriously".
This is similar to what the testing flag in the current SSP draft says.
These statements aren't really declarative; they're a request, and I'd
rather that the choice of words not preempt this discussion.
The DKIM working group will produce a summary of the threats that are
addressed by the standards-track specifications, while acknowledging
their
limitations and scope. The DKIM working group will also produce security
requirements to guide their efforts, and will analyze the impact on
senders
and receivers who are not using DKIM, particularly any cases in which
mail may be inappropriately labeled as suspicious or spoofed.
I got a little confused by the use of "standards-track specifications"
here, because the threat analysis is done before any standards-track
specifications exist. Should it say "DKIM specifications" instead?
While the techniques specified by the DKIM working group will not prevent
fraud or spam, they will provide a tool for defense against them by
assisting receiving domains in detecting some spoofing of known domains.
The standards-track specifications will not mandate any particular
action by
the receiving domain when a signature fails to validate. That said,
with the understanding that guidance is necessary for implementers,
the DKIM
documents should discuss a reasonable set of possible actions and
strategies,
and analyze their likely effects on attacks and on normal email delivery.
The DKIM working group will not attempt to establish requirements for
trust
relationships between domains or to specify reputation or accreditation
systems.
Last sentence: "or" -> "nor"
The DKIM working group will consider mailing-list behaviour that is
currently deemed acceptable, will make every effort to allow such
mailing lists to continue to operate in a DKIM environment, and will
provide a plan for smooth transition of mailing lists that fail to
operate. The specs will also advise mailing lists on how to take
advantage of DKIM if they should choose to do so.
"specs" (which should probably be spelled out) is plural. Is that to
say that all of the documents will say something about mailing lists? I
tend to think that this is somewhat of a higher-level issue than the
-base document addresses.
[snip]
The deliverables for the DKIM working group are these:
* An informational RFC providing an overview of DKIM and how it can fit
into overall messaging systems, implementation and migration
considerations, and outlining potential DKIM applications and future
extensions.
* An informational RFC presenting a detailed threat analysis of, and
security requirements for, DKIM. IESG approval of this document is a
prerequisite for the submission of the standards-track specifications.
Is this typical for threat/security requirements documents? How long is
it likely to take (and is it likely to interfere with the schedule for
the signature schedule specification Last Call)?
* A standards-track specification for DKIM signature and verification.
* A standards-track specification for DKIM policy handling.
* A standards-track specification for a DKIM DNS Resource Record.
The current drafts have two DKIM RRs, one for keys and another for
"policy". So that should be Resource Records. Hopefully we can still
fit them into a single specification.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org