Subject: [ietf-dkim] new issue: clarify i= vs. SSP

From: Michael Thomas <[email-masked]>
Date: Wed, 29 Nov 2006 13:44:39 -0800

Hi,

One of the things I noticed from recent discussions is that we need to
have clarity in SSP on what, exactly, qualifies as a valid signature for
"I sign everything". This guidance is not in dkim-base (purposefully),
but I believe that we had intended i= to provide that clarity. In any case,
we do need to provide the exact semantics in SSP of how a
receiver determines whether a DKIM signature satisfies the SSP
criteria or not.

I'm not sure whether this rises to a -ssp-req item or not -- I sort of
lean toward it just to make certain that it is tracked. Or if there's a
bunch of disagreement about what satisfies the SSP criteria, then
it most likely should be...

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Nov 2006 18:24:24 -0800

On Nov 29, 2006, at 1:44 PM, Michael Thomas wrote:

> I'm not sure whether this rises to a -ssp-req item or not -- I sort  
> of lean toward it just to make certain that it is tracked. Or if  
> there's a bunch of disagreement about what satisfies the SSP  
> criteria, then it most likely should be...

This should be tracked.

DKIM policy (which should include domain associations) must not be  
limited to just one email header.  Visual recognition of a From email  
address is confounded when displaying UTF-8, where an ACE label or  
different character repertoires might be used.  Surely no one expects  
people to visually validate puny-code conversions or inspect  
character codes.  This is just one problem related to visual  
recognition strategies.  This situation becomes even more problematic  
as the From header itself changes roles.  The sooner the DKIM WG  
acknowledges a visual recognition strategy is seriously (if not  
fatally) flawed, the better.  DKIM must be used in conjunction with  
trusted lists such as address-books for there to be spoofing  
protections.

Proponents of visual recognition proclaim messages (such as those  
passed through a mailing-list) should be rejected to support this  
highly flawed strategy.  A visual recognition protection scheme is so  
flawed as to be dangerous when describing visual recognition in  
conjunction with authorization as protection.  Bad actors will adapt,  
and be rewarded with a means to gain a recipient's confidence.  It is  
hard to imagine a worse strategy.  There is no reason for DKIM to be  
so disruptive with current and future email applications.

An authorization/visual recognition strategy will likely only block a  
few percent of spoofing attempts once countered.  An annotation  
scheme based upon "listed" recognition schemes will not disrupt use  
of mailing-lists or the EAI efforts, for example.  Once dependence  
upon visual recognition has been set aside as flawed, then other  
headers can be afforded protection under an annotation/trusted list  
strategy.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Nov 2006 16:20:00 +0100

Michael Thomas wrote:

> we need to have clarity in SSP on what, exactly, qualifies as a valid
> signature for "I sign everything". This guidance is not in dkim-base
> (purposefully), but I believe that we had intended i= to provide that
> clarity. In any case, we do need to provide the exact semantics in SSP
> of how a receiver determines whether a DKIM signature satisfies the SSP
> criteria or not.

+1

We could explain that i= matching the domain part of the "PRA" indicates
a first party DKIM signature, even if 2822-From != "PRA".  Where "PRA" is
of course only a new name for something already specified in RFC 2822, or
even in STD 11, if there's only one Resent-* block.  It's no proprietary
algorithm.  RFC 4407 is just a summary of facts extracted from RFC 2822.

Frank

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Nov 2006 08:27:46 -0800

Michael Thomas wrote:
> "I sign everything". 

Michael,

To carry your point farther than I suspect you intend:

 From the virtually all of the SSP discussions, including recent exchanges, I 
keep thinking that we are starting with mechanism and only secondarily worrying 
about utility.  Hence the grou confusion that is persistent.

Some folks think of SSP as being for unsigned mail.  Some folks think of SSP to 
facilitate end-user interpretation.  Some folks think...  And so on.

What we do not seem to have is anything that looks like a clear consensus about 
what problem is being solved and why it will be useful to solve it.

Until the group settles on specific benefits to be obtained, for which there is 
a solid basis to think recipient operators will find them useful, we are chasing 
our collective tail.

I suggest that discussion about technology -- that is, mechanisms -- should be 
deferred until the receive-side benefits (and, for that matter, the receive-side 
consuming component) are established.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 30 Nov 2006 09:11:23 -0800

Dave Crocker wrote:
> From the virtually all of the SSP discussions, including recent 
> exchanges, I keep thinking that we are starting with mechanism and 
> only secondarily worrying about utility.  Hence the grou confusion 
> that is persistent.
>
> Some folks think of SSP as being for unsigned mail.  Some folks think 
> of SSP to facilitate end-user interpretation.  Some folks think...  
> And so on.
>
> What we do not seem to have is anything that looks like a clear 
> consensus about what problem is being solved and why it will be useful 
> to solve it.
>
> Until the group settles on specific benefits to be obtained, for which 
> there is a solid basis to think recipient operators will find them 
> useful, we are chasing our collective tail.
>
> I suggest that discussion about technology -- that is, mechanisms -- 
> should be deferred until the receive-side benefits (and, for that 
> matter, the receive-side consuming component) are established.
Dave --

I view this exercise as a largely unproductive rathole. I think there's 
been a consensus
for quite a while that the information provided would be interesting to 
a pretty widely
varying set of people. Like dkim-base, I don't think we need to 
enumerate with any
precision what those benefits are as will undoubtably fall into the 
false dilemma of
trying to rank them, categorize them, etc. I can't see how that is 
helpful because it's
very clear that that way consensus does not lie. Nor need it, IMO.

On the sender/signer side there is a fairly simple benefit: SSP is an 
information
service which domains publish to give receivers more accurate details 
for their
delivery decisions. Nothing more. I think that's pretty much all of the 
justification
we need.

Much more interesting in my mind is whether there's potential *harm* that
might come from SSP, and if so whether the draft can do anything to 
avoid that
harm, how likely the harm would be, etc.

       Mike

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 12:46:33 -0500

Any harm would come from benign harm, misconfigured SSP and misled
receiver policies.

Mal harm would be from spoofing authors thru valid 3rd party signers 
From: [email-masked]
Sender: [email-masked]
DKIM: valid signature

When bar.com SSP states I sign all mail, foo.com has no SSP entry and
[email-masked] didn't author the message

Im sure there is other harmful methods

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Thursday, November 30, 2006 12:11 PM
To: [email-masked]
Cc: ietf-dkim WG
Subject: [ietf-dkim] new issue: requirement to enumerate receiver
sidebenefits of SSP?

Dave --

Much more interesting in my mind is whether there's potential *harm*
that
might come from SSP, and if so whether the draft can do anything to 
avoid that
harm, how likely the harm would be, etc.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 30 Nov 2006 09:45:58 -0800

On Nov 30, 2006, at 9:11 AM, Michael Thomas wrote:

>> Some folks think of SSP as being for unsigned mail.  Some folks  
>> think of SSP to facilitate end-user interpretation.  Some folks  
>> think...  And so on.
>>
>> consensus about what problem is being solved and why it will be  
>> useful to solve it.
>>
>> Until the group settles on specific benefits to be obtained, for  
>> which there is a solid basis to think recipient operators will  
>> find them useful, we are chasing our collective tail.
>>
>> I suggest that discussion about technology -- that is, mechanisms  
>> -- should be deferred until the receive-side benefits (and, for  
>> that matter, the receive-side consuming component) are established.
> Dave --
>
> I view this exercise as a largely unproductive rathole.

+1

> I think there's been a consensus
> for quite a while that the information provided would be  
> interesting to a pretty widely

-1.

I don't believe that that's been demonstrated yet, at least not
with plausible real-world use cases. Certainly none are
documented in anything other than the vaguest, least useful,
most abstract way anywhere that I've seen.

Enumerate? No. But demonstrating the existence of enough
use cases (>0) to show that some people sending email actually
have a need for SSP, and that enough diverse groups (>1) have
a need for it to justify a public standard created by someone other
than those users would go a long way towards justifying SSPs
benefits as outweighing its costs and risks.

>
> On the sender/signer side there is a fairly simple benefit: SSP is  
> an information
> service which domains publish to give receivers more accurate  
> details for their
> delivery decisions. Nothing more. I think that's pretty much all of  
> the justification
> we need.
>

Well, SSP will cause legitimate email to be rejected, so there is
non-zero potential harm. It's likely that in at least some cases the
benefit will outweigh that harm, but we'd really need to look at
some of the actual use cases that a sender may use SSP for
to say for sure.

(Depending on how SSP is used it's possible that it may cause much
more drastic harm, but I don't want to go into that possibility again,
given the abuse it provoked last time.)

Cheers,
   Steve