ietf
[Top] [All Lists]

Re: DKIM Signatures now being applied to IETF Email

2011-08-02 16:32:28
Dave CROCKER wrote:

On 8/1/2011 8:41 AM, Scott Kitterman wrote:
In fairness to Hector, the functionality that he is complaining is missing was
part of the original working group charter.


please cite the text from the original charter that promises such work and, just to be safe, please cite the current text that claims it should be there.

In other words, the current complaint is about something missing. Please quote the specification of that and then the part of the original charter that said we would do it.

We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item.

The DKIM WG always had among its charter work items to produce a Domain Policy standard and even thought the charter was revised over the years, Policy is still today among the WG chartered item today. I personally have not seen or read of any official statement to conclude the WG and stop all remaining work, nor a change in the charter to official remain policy as a work item.

Attached is 2005 copy of the charter I have on disk. Please note how reputation was declared of out of scope, yet it continued to disrupt the WG and revamped DKIM to its present condition.

Two other WG RFC work items were completed; one directly related to producing the "Requirements for a DKIM Signing Practices Protocol" RFC5016, and a Threat Analysis RFC4686 which includes among its analysis how policy can mitigate certain security threats using Policy.

You, yourself, wrote a RFC5585 called

    "DomainKeys Identified Mail (DKIM) Service Overview"

with signing practices peppered over all the document as a major piece of the system. This sentence is found in the abstract:

   DKIM also enables a mechanism that permits potential email signers to
   publish information about their email signing practices; this will
   permit email receivers to make additional assessments about messages.

And the RFC includes a spiffy process flow illustration titled

      "DKIM Service Architecture"

with a Checking Signing Practice component as a major piece of this design.

So I am "scratching my head" here wondering why you are now questioning how a framework designed over 5 years had major work productions dismissed, especially those related to security, in the pursuit of the unrestricted resigner and 3rd party trust vendor service market and now seem to suggest the DKIM WG Domain Signing Practices standardization efforts was not a work item and never existed in the first place as a charter item, when in fact, it is still today a WG charter item.

Very odd.

--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


DRAFT IETF WORKING GROUP CHARTER  
14 Oct 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 
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.

The DKIM working group will produce summaries 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.

While the techniques specified by the DKIM working group will not prevent 
fraud or spam, they will provide a valuable tool for defense against them by 
allowing receiving domains to detect spoofing of known domains.  The 
standards-track specifications will not mandate any particular action by the 
receiving domain when spoofing is detected.  The DKIM working group will not 
attempt to define such actions, to establish requirements for trust 
relationships between domains, or to specify reputation or accreditation 
systems.  

The signatures will use public-key cryptography and will be based on domain 
name identifiers.  Public keys needed to validate the signatures will be 
stored in the responsible identity's DNS hierarchy.  The specifications will 
be based on the following Internet Drafts: 

* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp

which represent experimentation and consensus from a number of designers and 
early implementors.  
 
Since experimentation resulted in significant Internet deployment of these 
specifications, the DKIM working group will make every reasonable attempt to 
keep changes compatible with what is deployed, making incompatible changes 
only when they are necessary for the success of the specifications.  

The resulting protocols must meet typical criteria for success.  In addition 
to security, these include usability, scalability, ease of deployment, and 
cryptographic algorithm independence.  

To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group.  These topics include:

* Reputation and accreditation systems.  While we expect these to add value 
  to what is defined by the DKIM working group, their development will be 
  separate, and is out of scope for the DKIM working group.  

* Message content encryption.  

* Additional key management protocols or infrastructure.  

* Signatures that are intended to make long-term assertions beyond the 
  expected transit time of a message from originator to recipient, which is 
  normally only a matter of a few days at most.  

* Signatures that attempt to make strong assertions about the identity of 
  the message author, and details of user-level signing of messages (as 
  distinguished from domain-level keys that are restricted to specific 
  users).

* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.  

Once the primary goals are met, the DKIM working group may also study 
whether to adopt a work item for specifying a common mechanism to 
communicate the results of message verification to the message recipient.  
The generation of a standards-track specification will require an update to 
the DKIM working group charter.  

The deliverables for the DKIM working group are: 

* an informational RFC providing an overview of DKIM, how it can fit
  into overall messaging systems and outlining potential DKIM applictions
  and future extensions
* an informational RFC presenting a detailed threat analysis of, and 
  security requirements for, DKIM
* 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


GOALS AND MILESTONES:

02/06     WG last call on DKIM threats and security requirements
05/06     WG last call on DKIM signature specification
09/06     WG last call on DKIM policy specification
12/06     WG last call on DKIM DNS Resource Record
12/06     WG last call on overview document

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf