ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM charter

2005-11-14 15:10:44
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

<Prev in Thread] Current Thread [Next in Thread>