Subject: [ietf-dkim] Requirements on how SSP stuff is found...

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jul 2006 11:37:12 +0100

A similar question to the previous one.

Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.

Are there any other requirements there or is that the only
basis on which we need to be able to search for SSP stuff?

Stephen.

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Jul 2006 07:12:00 -0700 (PDT)

> basis on which we need to be able to search for SSP stuff?

You need to be open to other possibilities and make system easily
extendeable to other identities. My preference would be to encode
identity in the lookup path, so instead of doing lookup on _policy
it would actually be done against _from._policy indicating that
this is record for From header field use policy.

As far as other identities one obvious is email originator which
in current email system model corresponds to Sender: header field
(From if Sender is not present).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jul 2006 11:54:29 -0700

> the domain part of an unsigned message's RFC2822.From element.

Yes, that is clearly a core assumption.  I suggest that we need to explain the
basis for that assumption and that the explanation needs to provide the
empirical basis for believing that it is the right choice.  In other words, how
is it supposed to be used/useful and why do we believe it will work?

d/

-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 28 Jul 2006 14:46:32 -0700

> this is record for From header field use policy.
How do you then decide which policies to check?  Does this mean that you
need to check every address corresponding to a From, Sender,
Resent-from, Resent-sender, 2821 envelope-from, and List-id, for every
message you receive, just in case there's SSP data in any of those
places?  This sounds like a really onerous requirement.

-Jim

---

From: Mark Delany <[email-masked]>
Date: Fri, 28 Jul 2006 22:01:56 +0000

> places?  This sounds like a really onerous requirement.

Right. The "Which I" problem.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jul 2006 15:35:32 -0700

Mark Delany wrote:
>> Resent-from, Resent-sender, 2821 envelope-from, and List-id, ...

Indeed.  I suspect the challenge, here, is to decide which *few*, real threats
are serious enough to warrant a solution.

By contrast, an exhaustive exercise to think of every possible scenario that we
might feel like covering seems like a good way to a) reduce the overall
relevance of the work, and b) make the mechanism big enough and complex enough
to be difficult to implement properly.

d/
-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jul 2006 15:52:45 -0700

On Jul 28, 2006, at 3:35 PM, Dave Crocker wrote:

>
>
> Mark Delany wrote:
>>> How do you then decide which policies to check?  Does this mean  
>>> that you need to check every address corresponding to a From,  
>>> Sender, Resent-from, Resent-sender, 2821 envelope-from, and List- 
>>> id, ...
>>
> Indeed.  I suspect the challenge, here, is to decide which *few*,  
> real threats are serious enough to warrant a solution.
>
> By contrast, an exhaustive exercise to think of every possible  
> scenario that we might feel like covering seems like a good way to  
> a) reduce the overall relevance of the work, and b) make the  
> mechanism big enough and complex enough to be difficult to  
> implement properly.

There needs to be a strategy to limit the number of signature  
verifications and identities checked, or the verifications and  
lookups themselves may create a threat.

Originator Address (OA) (2822.From(s))

Current Address (CA) (2822.Resent-Sender-> Resent-From(s)-> Sender-> OA)

Limiting the effort to the OA seems appropriate.  Is there a  
significant threat related to CA spoofing?

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 31 Jul 2006 07:57:18 -0500

I'll take a crack at this one.

 > I suggest that we need to explain the basis for that assumption and
 > that the explanation needs to provide the empirical basis for
 > believing that it is the right choice.

The "From:" header value is the identity the naive user assumes to be 
the originator due to the vast majority of mail clients which have 
trained them to assume so.  Thus it has a property, for better or worse, 
which no other header has.  Therefore, from a domain owners point of 
view (who is interested in protecting the integrity of his domain in the 
minds of naive users as far as possible), "From:" header value seems a 
wise selection.

 > In other words, how is it supposed to be used/useful

It's useful if understood from the domain owners point of view.  The 
domain owner wishes to be "consulted" concerning their signing practice 
if their domain is being presented by the MUA to an end user.  At least, 
this is the capability I think SSP is trying to provide to domain owners.

I'm sure I'm not understanding some fundamentals and problems hidden in 
all this but I'm equally sure that I will receive and will welcome some 
educating.

-- 
Arvel

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 06:34:21 -0700 (PDT)

On Fri, 28 Jul 2006, Jim Fenton wrote:

> How do you then decide which policies to check?

Decision on which policies to check is the same as which DNSBL to use -
in other words its up to the receiver to decide what it is going to do
(or if it going to use mail signatures for its decisions at all).

> Does this mean that you

[you forgot "Reply-To"]

And with 3/4th or more of emails there is no issue. For others there maybe 
additional identities of interest depending on what classification system 
is to be used but its actually not quite as bad as that you check every
domain of every header field because in reality number of identities is 
small and they are compound and produce one address (i.e. originator 
is compound of Sender/From, reply address is compound of Reply-To/From, 
etc). I'm not against you only doing it only for From (how is that doing 
with multiple addresses in From being possible btw) for now but the record 
syntax and dns should be capable of being extended.

P.S. When was the last time you did ethereal to see what your anti-spam
software is doing?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Jul 2006 14:53:51 +0100

Hi Arvel,

> minds of naive users as far as possible), "From:" header value seems a 

But the SSP client is not the naive user - its a DKIM-verifier. Does
that change the argument? E.g. in terms of requiring consideration of
other "identities" or "domains" found in the message? (Just asking.)

S.

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 31 Jul 2006 12:20:20 -0500

> other "identities" or "domains" found in the message? (Just asking.)

If an SSP client could consider other identities/domains found within 
the message and that consideration could assist in determining the 
authentic/non-authentic question then yes that would be very useful 
input for a verifier.  I'd be all for it.  I hope I understood the 
question correctly :)

-- 
Arvel