Subject: Re: [ietf-dkim] A few SSP axioms

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 08:26:29 -0700

John L wrote:

> I have to say that the more discussion I see from advocates of SSP, 
> the less I think that anyone really understands what it's supposed to do.
>
> So here's the main SSP axiom that I think should be self-evident, but 
> apparently isn't: other than the trivial (but useful) case of I send 
> no mail, the most that SSP can tell you is that a signature is missing.
>
> If a message has a signature, no amount of SSP can unsign it.  It 
> might be able to say that a signature is missing, e.g., it's signed by 
> your ISP but the SSP says it's supposed to be signed by you, too.
>
> The other axiom is that any useful SSP statement (again excepting I 
> send no mail) contains "all".  Statements like "I sign some mail" are 
> useless, because they validate any message, signed or not.  Statements 
> like "I sign no mail" are useless because recipients will already have 
> figured that out when they see no signatures, or else your SSP is 
> broken if they do see signatures.

These don't seem axiomatic in any way that I can tell. The latter is 
just an optimization
of "I sign all of my mail". What is being lost here is that forensic 
information is often very
useful, so there is a very clear difference between publishing a policy 
that says "I don't
sign everything" and no policy at all from a forensic standpoint. Ditto 
with "I don't sign
anything."

Instrumenting protocols -- especially when you're not very sure of how 
the beast works --
seems like just plain good sense engineering.

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 10:52:03 -0700

John L wrote:

>> But suppose example.com is not a customer of isp.com but yet a message
>> from example.com has a valid signature from isp.com.  Are you saying
>> that Y! should say that it believes it came from example.com, based on
>> the assertion by isp.com that it only signs third-party messages?
>
>
> We certainly seem to have a lot of ambiguity if not confusion about 
> terminology.
>
> If a receiver is going to be looking up SSP data, is it going to look 
> up the domain in a message's signature?  In the From: line?  In some 
> PRA-ish function of various headers?  All of the above?  Some of the 
> above in a fixed order?  Some of the above in an 
> implementation-dependent order?

The current requirement as I've captured it is that SSP in only about 
RFC2822.From
(1st party) and what you do if there is not a valid signature on behalf 
for From. At
least that what I've seen the most consensus for, and I frankly don't 
understand any
other definition assuming someone's offered one up.

>
> Can an additional signature ever decrease a message's reputation?  I 
> would argue no.
>
> If a message has a valid signature from the same domain as the From: 
> domain, can SSP tell you anything useful?  If you looked up the SSP on 
> such a message and it said "we send no mail", who do you believe?  
> (Keep in mind that if the signature is valid, the same DNS that had 
> the SSP also had the DKIM key.)

Good question -- does it raise to a protocol requirement or just a 
design consideration
to provide an answer?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 11:02:49 -0700

Jim Fenton wrote:

>Michael Thomas wrote:
>  
>
>>John L wrote:
>>    
>>
>>>I still don't understand the scenario.  Let's call the domain isp.com.
>>>Is it:
>>>
>>>A) No mail has an isp.com From: address, but mail with other From:
>>>addresses may have an isp.com signature.
>>>      
>>>
>>Consider what I believe Y! does in their MUA: if it's got a valid
>>signature from isp.com
>>with a From: [email-masked], it doesn't get a nice little message
>>saying that Y!
>>believe it came from customer.com. Thus the outsourced mail will not
>>be treated on
>>a par with mail signed on behalf of the domain.
>>
>>That's something.
>>    
>>

Certainly not.

>Maybe I have trimmed off too much context here, I thought we were
>discussing the value of an "I only sign third-party messages".  I'm with
>John; I don't see how that provides any useful information to the verifier.
>
>  
>
Maybe it's me that's missing the context then. I don't see that as 
especially
informative either.

       Mike