Subject: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871-errata (RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 24 Apr 2009 06:25:29 -0700 (PDT)

The IESG has received a request from the Domain Keys Identified Mail WG 
(dkim) to consider the following document:

- 'RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update '
   <draft-ietf-dkim-rfc4871-errata-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-05-08. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871-errata-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18143&rfc_flag=0

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Doug Otis <[email-masked]>
Date: Tue, 28 Apr 2009 11:54:56 -0700

http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata-04

Errata:

Original Text:
,---
The tendency is to have the MUA highlight the address associated with  
this *signing identity* in some way, in an attempt to show the user  
the address from which the mail was sent.
'---
Corrected Text:
,---
The tendency is to have the MUA highlight the SDID,  in an attempt to  
show the user the identity that is claiming responsibility for the  
message.
'---

This text revises the meaning of the original RFC .  The over-reaching  
errata represents an effort to simplify output elements that are  
obtained from DKIM signatures.  This simplification is already in  
conflict with the recent Authentication-Results header RFC5451, and  
misrepresents the i= value as an unimportant element contained within  
the DKIM signature.  In addition, when the i=value (AUID) is not  
present within the signature, it defaults to being the d= value (SDID).

Properly corrected without changing definitions or roles, the text  
could be as follows:
,---
The tendency is to have the MUA highlight the address associated AUID,  
in some way, in an attempt to show the user the address from which the  
mail was sent..
'---
  or
,---
The tendency is to have the MUA highlight the AUID, in an attempt to  
show the user the on-behalf-of identity asserted by the authoritative  
SDID.  Please note that the AUID or its default value will always  
include the SDID, the domain claiming responsibility for the message.
'---

Use of the AUID ensures intra-domain sources can be differentiated by  
recipients.

Section 3.5 of the current RFC4871:
,---
  d=  The domain of the signing entity (plain-text; REQUIRED).  This  
is the domain that will be queried for the public key.  This domain  
MUST be the same as or a parent domain of the "i=" tag (the  signing  
identity, as described below), or it MUST meet the requirements for  
parent domain signing described in Section 3.8.  When presented with a  
signature that does not meet these requirement, verifiers MUST  
consider the signature invalid.
'---

Here are some examples that argue against making this errata  
simplification:

Scenario:
A domain establishes a mailing-list within a sub-domain of their user  
domain.  The user domain asserts ADSP restrictions based upon the From  
email-address domain.

In the case of a sub-domain use, the Authentication-Results header  
presently collects the i= value, where the i= value is expected to  
provide information to assist the MUA with message annotations.

A message from the mailing list might signed as follows:

Sender: [email-masked]
From: [email-masked]
DKIM-Signature: i=[email-masked];
   d=example.com; ...

A message from a user within the domain might be signed as follows:

From: [email-masked]
DKIM-Signature: i=[email-masked];
   d=example.com; ...

By allowing annotation of the Sender header field when from the  
Mailing-List versus the From header field when from authenticated  
users, a recipient can recognize different sources within the domain  
that might provide different levels of authentication while still  
purporting to be from the same author.

Another example might be:

Sender: [email-masked]
From: [email-masked]
DKIM-Signature: i=[email-masked];
   d=example.com; ...

Here a message may have been authenticated as being sent by the office- 
admin on behalf of jon.doe,  The DKIM signature indicates it was added  
on behalf of the office-admin.

Another example of a possible valid signatures that might be:

Sender:[email-masked]
From: [email-masked]
DKIM-Signature: i=[email-masked];
  d=example.com; ...

A valid DKIM signature by the SDID verifies that it is authoritative  
for the namespace used within the AUID.  This namespace may not always  
match against header fields, nor is this namespace assured to always  
represent  valid email-addresses.  When the i= value does not match  
against a signed header field, it may instead represent an internal on- 
behalf-of identifier.  Perhaps the MUA may wish to annotate both  
header fields, or perhaps none when the Sender header field is not  
being displayed.  Either way, the i= value represents a important  
output of the DKIM signature header specifically intended for  
consumption by the MUA as currently stated by RFC4871 and supported by  
RFC5451.

A valid DKIM signature would be analogous to a tamper resistant  
laminate placed on a driver's license.  The signing domain, or SDID,  
would be analogous to the State issuing the license.  The i= value, or  
AUID, would be analogous to the driver's ID registered with the  
State.  Both the State and the registered driver ID represent critical  
and essential identifiers.  A driver's license lacking any driver ID  
would be fairly useless whenever there is a need to assess  
responsibility, and yet the change being made in the errata takes away  
the driver's ID.

Please, don't emasculate DKIM with an errata.  Being able to track  
intra-domain identifiers may become an essential element needed to  
deal with possible DKIM signature replay abuse.  Without this  
convention, likely essential for larger domains, DKIM based behavior  
assessments become meaningless without path based registration.   
Extending DKIM by adding other headers will be highly problematic as a  
retro-active repair of damage caused by the errata.

-Doug