Subject: Re: [Asrg] Third party DKIM signatures

From: "Walter Dnes" <[email-masked]>
Date: Thu, 1 Jun 2006 00:52:38 -0400

On Wed, May 31, 2006 at 06:26:25PM -0600, Dan Oetting wrote

> For the interim, a user could subscribe to a list through an ISP
> that adds DKIM signatures. Instead of the mailing list needing to
> determine the trust of the ISP it is the user that assigns trust
> to the ISP that carries his messages. Only a forgery that used the
> same ISP would then be accepted by the list. It would be up to the
> user to then sort the problem out with the ISP.
> 
> It may help to preemptively address the forgery issue if the ISP
> were to insure that the From address were valid before signing the
> message. But this is an issue between the ISP and the user. If an
> ISP is going to allow forged addresses why would their signature
> verifying the address make any difference?

  Real-life question...
  1) How does any ISP (beyond a really small geek outfit) verify that I
am authorized to use [email-masked] ?

-- 
Walter Dnes <[email-masked]> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 1 Jun 2006 05:15:53 -0000

>am authorized to use [email-masked] ?

They don't.  Fortunately, that's not what the ISP's signature means.
All a DKIM signature means is "you can blame us for this mail."

In your case, I'd think it'd make sense to put on a signature from
waltdnes.org to say the mail is really from your domain, and another
signature from your ISP to say it was sent through them.

We do seem to have a chronic problem of people attempting to impute
extra semantics to DKIM signatures, don't we?  

If the signing domain matches the From: domain, should we take that to
mean that the From: address is real?  I don't think we should assume
that unless the whole address is in the signature, maybe not even
then.

R's,
John

---

From: Seth Breidbart <[email-masked]>
Date: Thu, 1 Jun 2006 01:32:14 -0400 (EDT)

> am authorized to use [email-masked] ?

Ask [email-masked]

Seth

---

From: "Dan Oetting" <[email-masked]>
Date: Thu, 1 Jun 2006 09:51:47 -0600

> All a DKIM signature means is "you can blame us for this mail."

If the signing domain is taking the blame for the email they emmit,  
eventually they are going to tire of holding the blame and act to  
shift the blame where it belongs or at least stop the abuse that they  
are being blamed for. Except in the case of open relays I think we  
can safely assume that the signing domain has some knowledge of the  
sender to which the ISP will be able to pass the blame.

If the signing domain is authenticating the sender, which they have  
to do in order to not be an open relay,  then the DKIM signature can  
be used as an extension of that authentication. As the example I  
presented, the user could tell a list server that the specific DKIM  
signing domain is a required element when accepting mail from that  
user. This would block most forgeries on that list except for  
forgeries that came from the same ISP. This local conflict can then  
easily be resolved by either the ISP removing the forger or the user  
removing himself from the ISP.

Note that this particular linking of the signing domain to the From  
address is local to the receiving list server and at the request of  
the user.

> that unless the whole address is in the signature, maybe not even

A sender could always forge any address used in the signature. An ISP  
that blindly signs the outgoing mail would inadvertently sign such a  
forgery. Unless there is an explicit flag that says a header has been  
verified you cannot infer anything more about the signed header  
except that it was a part of the original message. I haven't looked  
at any cases yet where such a flag would make DKIM signatures more  
useful.

-- Dan Oetting

---

From: "Dan Oetting" <[email-masked]>
Date: Thu, 1 Jun 2006 10:41:31 -0600

> am authorized to use [email-masked] ?

A simple verification procedure would be to quarantine outgoing email  
with unknown From addresses until the owner responded to a  
confirmation request. This would present a difficulty for you if you  
used a different From address for every outgoing email. The ISP may  
decide to only verify your authorization once for any domain and  
assume that any internal squabbles for forgeries within a domain are  
someone else's problem.

Note that here I am only talking about an ISP preventing forged  
addresses from being sent from their mail servers for which they  
would be blamed. This part has nothing directly to do with DKIM  
signatures.

-- Dan Oetting

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Jun 2006 09:52:17 -0700

On Jun 1, 2006, at 9:41 AM, Dan Oetting wrote:

> A simple verification procedure would be to quarantine outgoing  
> email with unknown From addresses until the owner responded to a  
> confirmation request. This would present a difficulty for you if  
> you used a different From address for every outgoing email. The ISP  
> may decide to only verify your authorization once for any domain  
> and assume that any internal squabbles for forgeries within a  
> domain are someone else's problem.
>

There is an optional DKIM i= extension that defaults to a @<signing- 
domain> template.  The i= identity could be used to narrow the  
qualified source of subscribed messages.  When there is a specific  
email-address noted in the i= extension, there could be reason to  
presume the related email-address has been verified in some manner as  
belonging to the account granted access.  When this account is used  
by a large organization, resolution at the individual may remain  
doubtful.

-Doug

---

From: "Walter Dnes" <[email-masked]>
Date: Thu, 1 Jun 2006 19:18:09 -0400

On Thu, Jun 01, 2006 at 01:32:14AM -0400, Seth Breidbart wrote
> Ask [email-masked]

  Being "master of my domain", I can personally answer that question on
my own behalf.  Would Google or Yahoo be able to verify to example.com
that Joe Blow is authorized to send out email as [email-masked] or
[email-masked] when sending email from example.com?  Manual
confirmation doesn't scale.  Automating it opens up the potential for
address harvesting.

---

From: "David Nicol" <[email-masked]>
Date: Thu, 1 Jun 2006 19:05:00 -0500

On 6/1/06, Walter Dnes <[email-masked]> wrote:

>  Would Google or Yahoo be able to verify to example.com

spf plus a databse-based DNS can solve this.  joeblow registers with
yahoo's complex spf engine that he sometimes sends his mail from example.com,
and the receiving MTA hits a macro section in yahoo's spf record that
indicates how to build an A-record query to ask if he uses example.com
and the receiving MTA does the A-record lookup and bases the authorization
result on the result of the second DNS lookup, which looks something like

            example.com.isgoodnamedsourcefor.joeblow.morespf.yahoo.com

SPF classic provides macros for exactly this purpose; there is very
little potential
for harvesting without guessing; statistical techniques currently used to deny
access to guessers can be re-used to protect the dns service.

If guessing would be of any use at all, since you would need to guess
the user-part in
association with a non-standard relay that that user uses, in order to
get a useful
result from a guess.

morespf.yahoo.com would NOT provide zone transfers to the general public,
for instance.

-- 
David L Nicol
"fans of liza minelli should always be
disconnected immediately" -- Matthew Henry at Voxeo

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jun 2006 17:41:15 -0700

On Thu, 2006-06-01 at 19:05 -0500, David Nicol wrote:
> spf plus a databse-based DNS can solve this. 

SPF represents a highly dangerous scheme with respect to packet
amplification threats.  Synthesizing perhaps large amounts of data with
trick DNS servers for localpart SPF records continues to overlook
significant security concerns.  

> joeblow registers with
> little potential for harvesting without guessing; statistical
> techniques currently used to deny access to guessers can be re-used to
> protect the dns service.

More modifications to DNS?  Fortunately yahoo does not implement SPF.
Macros within SPF for qualifying user space remain highly prone to
harvesting without some type of blocking.  This blocking would however
be highly prone to DoS exploits.  In short, it will not work.

-Doug

---

From: John Levine <[email-masked]>
Date: 2 Jun 2006 02:17:54 -0000

>shift the blame where it belongs

So you're saying that you're not responsible for mail that your
mail servers send?  If so, please send us the IP addresses so we
can all blacklist them permanently.

>sender to which the ISP will be able to pass the blame.

knowledge of the sender != knowledge of From: addresses

I know who all my users are.  I do not know, nor particularly care,
what return addresses they put on their mail.  If one of them
misbehaves, there's plenty of info in the headers already to tell who
sent what.

>be used as an extension of that authentication.

Right.  This still has nothing to do with the From: or Sender: address
on mail that they send.

>forgery.

Right.  If the ISP gets complaints, it should do something about the
misbehaving user.  Otherwise it has no way to know what addresses its
users can legitimately use, and would best refrain from guessing.

If you think that the ISP should limit the addresses its users can use
in outgoing mail, you must already have forgotten the yelling and
screaming when some of Verizon's predecessors did that as a lame and
ineffective anti-spam measure.

R's,
John

---

From: "Dan Oetting" <[email-masked]>
Date: Thu, 1 Jun 2006 21:01:34 -0600

> confirmation doesn't scale.  Automating it opens up the potential for

What do you mean "Manual confirmation doesn't scale"? Unless you are  
one of those people that like to collect domains and enjoys mixing  
the sender domains and the From domains, the number of addresses that  
an individual would need to confirm would be quite limited.

I said earlier that the ISP could quarantine outgoing mail until the  
confirmation succeeded. Even better would be to reject the mail in  
the smtp transaction from the user to the ISP with a comment that a  
confirmation email has been sent to the From address. This has the  
same effect as a quarantine but provides immediate feedback to the  
user, allows the user to then resubmit the mail with a different From  
address and the ISP doesn't have to worry about quarantine queues.

-- Dan Oetting

---

From: John Levine <[email-masked]>
Date: 2 Jun 2006 03:50:09 -0000

>an individual would need to confirm would be quite limited.

I fear that we're suffering a major failure of imagination here.  I
know people who use thousands of e-mail addresses with various
permuations of date, correspondent, and type of mail.

>confirmation email has been sent to the From address.

What a complete waste of effort.  If I were an ISP using DKIM, I would
be sure there was a header in my outgoing mail with enough info to
identify the customer (opaque token is fine), and include it in the
signature.  Then if a recipient objects, I know who the guilty party
is regardless of what address he used.

R's,
John

---

From: "Dan Oetting" <[email-masked]>
Date: Fri, 2 Jun 2006 11:51:01 -0600

I did state in my first post:
>> message. But this is an issue between the ISP and the user.

I'm not suggesting that ISPs should be required to filter addresses.  
Just that for some ISPs it may be beneficial.

Because a DKIM signatures can provide indelible proof that abuse  
originated at a specific ISP, they are going to put added pressure on  
ISPs to control the abuse. Even after the ISP boots the abuser the  
evidence of the abuse will still exist.

Handling abuse after the fact will be fine as long as the cost to  
establish an account at your ISP is greater than the perceived  
benefit of using the account for abuse until it gets shut down.   On  
the other side, what if your ISP gets hit with a flood of abuse  
reports claiming that your users are using forged addresses.

-- Dan Oetting

---

From: Michael Thomas <[email-masked]>
Date: Fri, 02 Jun 2006 11:36:03 -0700

> evidence of the abuse will still exist.

Yeah, but... large providers suffer from the Usenet Death Syndrome -- 
that you
can threaten a provider, but the likelihood that you're ever going to 
pull the trigger
on them is really low. Maybe it works to some degree on the social/shame 
level, but
the technical level seems pretty remote. What _does_ seem more likely is 
that we'll
be able to get a better handle on senders who are abusive but not drawn 
from large
user populations, spammers being one form of that population. If we can 
set up a
situation where they are faced with two choices: stay in the ever 
increasingly toxic
sewer of unauthenticated messages, or authenticate their messages which 
allows
reputation to accrue, then we'll all be in a much better position. I 
guess the same goes
for third party signatures too.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Jun 2006 14:46:49 -0700

On Jun 2, 2006, at 11:36 AM, Michael Thomas wrote:

> Dan Oetting wrote:
>>
>> I'm not suggesting that ISPs should be required to filter  
>> addresses.  Just that for some ISPs it may be beneficial.
>>
>> originated at a specific ISP, they are going to put added pressure  
>> on  ISPs to control the abuse. Even after the ISP boots the abuser  
>> the  evidence of the abuse will still exist.
>
> Yeah, but... large providers suffer from the Usenet Death Syndrome  
> -- that you can threaten a provider, but the likelihood that you're  
> ever going to pull the trigger on them is really low. Maybe it  
> works to some degree on the social/shame level, but the technical  
> level seems pretty remote. What _does_ seem more likely is that  
> we'll be able to get a better handle on senders who are abusive but  
> not drawn from large user populations, spammers being one form of  
> that population. If we can set up a situation where they are faced  
> with two choices: stay in the ever increasingly toxic sewer of  
> unauthenticated messages, or authenticate their messages which  
> allows reputation to accrue, then we'll all be in a much better  
> position. I guess the same goes for third party signatures too.

A better conclusion would be that only the signing domain will be  
evaluated.  Self policing without high DNS transactional overhead can  
be accomplished with a combination of EHLO/signing-domain correlation  
in conjunction with opaque identifier revocation.  Hopefully a future  
extension.

Cataloging violations based upon individual email-addresses  
represents an immense amount of data that will be both costly and  
risky to distribute.  Identifying culpable entities by email-address  
in the case of DKIM is weak and easily risks possible litigation.   
Third-party services may report specific messages back to the signing  
domain for possible resolution, where the individual email-address  
would not likely play a significant role.  Although the base draft  
claims there will be reliance upon the email-address reputation,  
receivers and third-party services are far more likely to focus upon  
the signing domain with respect to message acceptance.

In the case of DKIM, making an assurance of an email-address by the  
signing domain explicit by including the i=<something> parameter  
increases the value of that information.  The existence of the i=  
parameter allows a presumption that the signing domain verified the  
use of the email-address.  The current strategy appears to mandate  
(or assume) all email-address use is verified.  Rather than jumping  
to likely a false conclusion an email-address within the signing  
domain has been restricted, by limiting this conclusion to the  
specific case where the i= parameter offers a localpart, there would  
be much less risk of reaching a dangerously invalid conclusion.

Annotation is the only way the results of DKIM become visible.  Even  
the threat document now places localpart exploits as both high impact  
and high probability.  Some type of localpart annotation will be  
required, where fewer false conclusions about signing domain  
assertions improves upon recipient security.  There is no need to  
become email-address use fanatics.  It should be a simple matter to  
compare normal domains utilized by friends, family and acquaintances  
in DKIM aware MUAs.  Only annotate the localpart as verified when  
there is an i=localpart assertion (or perhaps a matching prior opaque- 
identiifer).  Annotation must also use a trusted list of email- 
addresses (such as those found within the address book) to prevent  
localpart spoofing.

-Doug

---

From: John Levine <[email-masked]>
Date: 4 Jun 2006 00:50:34 -0000

>>> were to insure that the From address were valid

Who said anything about From addresses?  Like I said, the signing ISP
puts a token in one of the signed headers so it knows which customer
it was, regardless of what's on the From: line.  As I think we've gone
over more than once, it is extremely unlikely that an ISP would know
what addresses its customers were or were not allowed to use, and
arbitrary limits like you have to use the address that came with the
account don't work.

R's,
John

---

From: "Dan Oetting" <[email-masked]>
Date: Sun, 4 Jun 2006 20:20:45 -0600

> arbitrary limits like you have to use the address that came with the

As I have been saying all along, If your ISP is operating in a way  
that it cost the spammers more to establish a new account than they  
perceive they will gain by abusing their privileges till they get  
booted you should be fine by handling abuse after the fact. But when  
the criminals spammers invade your ISP using stolen credit cards and  
figure their costs at zero, will you be able to stop them fast enough.

ISPs are each going to approach this problem differently. Some will  
put in costly measures to verify the real user identities before an  
account is opened. Others will choose to prevent the abuse by  
filtering what gets out of their servers. I'm not going to argue that  
one way is better than another, the goal is to stop the abuse or at  
least reduce it to a manageable level.

I personally believe that legitimate users that are not part of the  
spam problem should be unencumbered by the anti-spam measures. My  
favored approach is to detect the abuse as quickly as possible,  
notify the ISP or other controlling party as directly as possible and  
have the abuse stopped before the rest of the net is significantly  
inconvenienced. Since filtering from addresses of legitimate users is  
against my personal belief I'm going to drop such discussions now.

-- Dan Oetting