ietf-dkim
[Top] [All Lists]

[ietf-dkim] Revisiting the charter.

2005-08-30 06:59:45
I do not think that the proposed charter discussions are converging. In
particular I think that the objective in the charter proposed by Dave is
too broad to be achievable through the limited mechanism described in
the charter. 

The problems with articulating the threat model are caused by the
mismatch between the objectives stated in the proposed charter and the
actual objectives. Restating the objectives in the charter allows the
question of 'forgery' to be placed in the correct context.

Restatement of the objective in terms of accountability rather than
forgery allows the objective to be tightly defined in a manner that is
clearly achievable. The purpose of DKIM is simply to allow a sender or
intermediary to accept responsibility for the message. 

Forgery then becomes an internal threat rather than an external one. I
think we are all very confident that we can deal with the internal
threat. The external threat is very hard to define, let alone address.
The phishing attacks target the bank brand, the domain name is
secondary. The objective in connection to spam is to avoid legitimate
mail being mis-identified as spam. The objective of the policy component
is to allow a sender to disclaim responsibility for email that does not
meet certain criteria.



DRAFT IETF WORKING GROUP CHARTER  
30 Aug 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:

Objective:

The objective of the DKIM working group is to provide: 

1) a mechanism that allows an email sender or intermediary to accept
responsibility for an email message in transit by adding a digital
signature. 
2) a mechanism that allows an email sender to disclaim responsibility
for an email message by means of a security policy.

Architecture:

The DKIM working group will produce standards-track specifications that
describe authentication of message headers using public-key signatures.
A key distribution mechanism will be described employing a key centric
architecture employing domain names as identifiers. A policy mechanism
will be described that supports publication of the sender DKIM
authentication policy. The key distribution and policy mechanism will be
encoded as DNS records and use the deployed DNS infrastructure for
transport.

Except where changes are deemed to be essential the specifications will
support interoperability with implementations based on the initial
proposal described in draft-allman-dkim-*.txt Internet-Drafts. 

The working group will NOT develop protocols or message formats to
support email encryption, reputation or accreditation. The working group
will NOT consider mechanisms for public key enrollment, long term key
management or non-repudiation.


GOALS AND MILESTONES:

  7/05     Issue initial Internet-Draft[s] of signature specification
 10/05     Submit to IESG - for DKIM threats and requirements
  2/06     Submit to IESG - DKIM signature specification
  2/06     Submit to IESG - DKIM public key Resource Record
  5/06     Submit to IESG - DKIM policy specification

_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] Revisiting the charter., Hallam-Baker, Phillip <=