Subject: [ietf-dkim] Proposed issues addressed by SSP-03 for closure

From: Jim Fenton <[email-masked]>
Date: Sat, 01 Mar 2008 06:55:59 -0800

I'd like to shorten the list of open issues, so I'll start with the 
issues that I consider clearly moot in the ASP draft (-ssp-03) or that 
are duplicates of other issues.  Hopefully these are non-controversial.

WG chairs, I'd like to ask that you direct the closure of the following 
issues, subject to WG consensus, of course:

> 1399    clarify i= vs. SSP

Duplicate of 1519.

> 1402    Applicability of SSP to subdomains

Duplicate of 1534.

> 1512    ssp should not link "all" and third parties

SSP-03 does not have any linkage to third-party signatures

> 1525    Restriction to posting by first Author breaks email semantics

SSP-03 puts no special emphasis on the first Author Address

> 1529    Change "originator" to "author"

"originator" is not used any more.

> 1530    replace use of term "suspicious"

New draft does not use the term.

> 1531    "does not exist"

The wording has changed slightly from "does not exist" to "does not 
exist in DNS", which I think answers this.

> 1532    revise list labeling

The referenced text isn't in the draft any more.

> 1533    strict vs. integrated

Neither term is used.

> 1535    Simplify SSP decision tree

It's a whole lot simpler now (and arguably, not even a "Decision tree" 
but instead a "lookup tree")

>        
> 1536    definition of action terms

Neither "reject" nor "bounce" appears in the draft any more.

> 1537    Reputation is out of scope or define it

The word "reputation" does not appear in the draft.

>  
> 1538    review and repair of normative vocabulary usage

The use of normative vocabulary has changed so extensively that if 
there's a problem now, it's should be a new issue.

> 1540    deprecate t=testing 

t=testing is gone.

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Mar 2008 18:01:41 +0000

Thanks for going through the list Jim.

So let's say that if there's no objection before the end
of the DKIM session in Philly, that we'll close the issues
as suggested by Jim.

I guess that also means that for the meeting we should focus
on the issues not listed below and those from the list below
that don't end up being closed.

Stephen.

---

From: John Levine <[email-masked]>
Date: 1 Mar 2008 23:08:53 -0000

>that don't end up being closed.

Could Eliot or someone make a list of the issues that are still open?

I went down the list on the tracker and as far as I can tell they
they're all closed, assuming that closed means we have rough consensus
on them.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Mar 2008 23:21:52 +0000

> Could Eliot or someone make a list of the issues that are still open?

That'll happen in a week-ish, once folks have got a chance
to look over the new I-D vs the tracker list.

> they're all closed, assuming that closed means we have rough consensus

That'd be nice. But we're not quite there yet I'll bet.

S.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 2 Mar 2008 01:22:13 +0100

Stephen Farrell wrote:

>> I went down the list on the tracker and as far as I can tell
>> they they're all closed, assuming that closed means we have
>> rough consensus on them.
 
> That'd be nice. But we're not quite there yet I'll bet.

"Discardable" is more "suspicious" than "reject" from my POV,
but you know that, and if necessary it can be fixed based on
new LC arguments => close 1530 + 1537 as "better than 'foo'".

Jim didn't mention the FWS issue, the draft has *WSP.  Now after
net-utf8 was approved I think it should be simplified to *SP, or
does anybody insist on using HTAB in DNS records ?  If not let's
say *SP and close the FWS-issue as well.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Sat, 01 Mar 2008 17:45:41 -0800

> they're all closed, assuming that closed means we have rough consensus

No, a bunch of them are in "new" state.  Not sure what the difference is 
between "new" and "open".  I see the whole list by clicking on the dkim 
link on the right side of the home page, which links to:

https://rt.psg.com/Search/Results.html?Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sat, 01 Mar 2008 17:50:26 -0800

> say *SP and close the FWS-issue as well.

That was intentional; there was some discussion among the authors about 
what the right resolution to the FWS issue, so since I was including 
only issues on which I expected there was unanimity, I left that one off.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Mar 2008 13:34:41 -0800

On Mar 1, 2008, at 6:55 AM, Jim Fenton wrote:

> issues that I consider clearly moot in the ASP draft (-ssp-03) or  
> that are duplicates of other issues.  Hopefully these are non- 
> controversial.
>
> WG chairs, I'd like to ask that you direct the closure of the  
> following issues, subject to WG consensus, of course:
>
>
>> 1399    clarify i= vs. SSP
>
> Duplicate of 1519.

Disagree.

Issue 1399 suggests i= might be included within an "all" signed  
policy, however lacks details.

Issue 1519 notes SSP policy requirements conflicts with RFC 4871 and  
recommends against restrictions on the i= parameter for unrestricted  
keys.

Per the DKIM charter of out-of-scope topics:

* 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, including S/MIME and
   OpenPGP.

Despite being out-of-scope, the SSP Author Signature definition  
dramatically changes i= parameter use in "compliant" signatures.  The  
change in i= parameter's use was made by stipulating "compliant"  
signatures containing the local-part of an identity must be on behalf  
of the entity within the From header.  RFC4871 never stipulated a  
valid signature's associated identity contain an email-address found  
within the message's headers, nor that this identity be specifically  
within the From header.

Compatibility with RFC 4871 is only achieved using identity ambiguous  
signatures in many cases, leaving verifiers to guess (wrongly in some  
cases) by looking up the header stack.  To retain specificity of non- 
 From header identities, an separate signature is required and it must  
properly overlap that of an ambiguous signature.  There is _no_ reason  
to assume providers will make assertions regarding the specific  
identity of the message's author.  Providers may wish, or be  
compelled, to use opaque tokens instead.  Whether such identity  
assertions are made is out of scope for DKIM.  Not surprisingly,  
limitations on identity assertions limited to specific email-addresses  
within the From header for SSP "compliance" is not compatible with RFC  
4871 either, in addition to being out of scope.

Use of the i= parameter containing a token representing the user or  
agent on whose behalf the signature was made offers a significant  
level of protection for receivers.  This protection can help curb  
abuse from compromised systems, especially when users are permitted to  
send messages irrespective of identities within From headers.  Abuse  
is normally controlled by identifying abusers, and not by constraining  
all the domain's users messages.  The level of constraint used should  
remain within the purview of the signing domains.  The protection  
afforded by a valid (even tokenized) on-behalf-of identity is lost as  
a result of the change imposed by the Author Signature definition.  A  
definition that demands _less_ information be conveyed in the signature.

A domain may wish to assert all of their messages are signed to raise  
the scrutiny given unsigned messages from their domain.  Nevertheless,  
the identity of the Author remains an independent and totally separate  
issue.  Ironically, this definition inhibits use of identities of  
those introducing the message and on whose behalf the signature was  
added when not also found within the From header.  Any issues related  
to the spoofing of the Author still remains within the signing  
domain's purview and can be prevented by not signing spoofed or  
abusive messages.

The only justification to limit "compliant" signatures to those  
identities found within the From header would be for messages signed  
with g= restricted keys.  Such messages should be flagged "non- 
compliant" regardless of what policy the domain publishes.  Such  
messages can easily represent abuse beyond the signing domain's  
purview.  Not flagging these messages as being "non-complaint" would  
impose a significant security risk fully independent of any SSP policy  
assertions or author identities.   SSP should only stipulate that  
signatures containing identities not found within the From header  
signed with g= restricted keys are to be considered "non-compliant"  
with _any_ domain signing policy.  In addition, such stipulations  
SHOULD NOT depend upon whether a policy has been published.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Mar 2008 13:44:29 -0800

Jim Fenton wrote:
> Not sure what the difference is 

No real difference at this point.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 03 Mar 2008 16:44:24 -0800

Just to be clear, I was proposing that we close 1399 as a duplicate of 
1519, not the other way around.

-Jim

Douglas Otis wrote:
>> that are duplicates of other issues.  Hopefully these are 
>> non-controversial.
>>