Subject: RE: [ietf-dkim] user level ssp

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 12:54:32 -0700

> [mailto:[email-masked]] On Behalf Of Steve Atkins

> On Sep 7, 2006, at 12:28 PM, Hallam-Baker, Phillip wrote:
> 
> >
> >> [mailto:[email-masked]] On Behalf Of John Levine
> >
> > Mostly +1
> >
> > But there could be utility in the sender saying 'My email 
> is at very 
> > serious risk of being impersonated'.
> 
> What is that utility? Please expand on what behaviour you 
> expect from the recipient and how that will differ from the 
> case where the sender does not say that.

If I know that you are a self declared target of phishing and that the consequences of letting a phish go through are considerably more serious than a random impersonation spam I can adjust my spam filters accordingly. 

In particular I would expect to filter out ALL mail automatically in the case that ALL the following apply:

  * The sender ALWAYS signs
  * The sender declares themselves to be at risk of phishing attack
  * The content is HTML
  * There are URIs in the body of the text message
  * The message has not been forwarded by a previously noted intermediary.

It is possible that a few such mails would be falsely suppressed but this mechanism provides a pretty good bright line. 

At the very least it gives me a tool that allows me to bring these messages to the immediate attention of the abuse desk.

There are ~100 million domains and only ~10,000 banks. Knowing what you are dealling with helps focus resources on the most significant problems.

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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Sep 2006 13:31:56 -0700

On Sep 7, 2006, at 12:54 PM, Hallam-Baker, Phillip wrote:

> If I know that you are a self declared target of phishing and that  
> the consequences of letting a phish go through are considerably  
> more serious than a random impersonation spam I can adjust my spam  
> filters accordingly.
>
> In particular I would expect to filter out ALL mail automatically  
> in the case that ALL the following apply:
>

How does that differ from the case where:

   * The sender ALWAYS signs
   * The content is HTML
   * There are URIs in the body of the text message
   * The message has not been forwarded by a previously noted  
intermediary.

I guess that the real question is  what's the difference between "I  
always sign"
and "I always sign and I get phished"?

The impression I'm getting, from several people, is that "I always  
sign" is already
being written off as likely to be ignored by recipients and that  
there needs to be
a "No, I really mean it!" modifier?

Cheers,
   Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 07 Sep 2006 14:01:52 -0700

On 2006-09-07 12:54, Hallam-Baker, Phillip wrote:

> the consequences of letting a phish go through are considerably more
> serious than a random impersonation spam I can adjust my spam filters
> accordingly.

But the opposite of that statement would be interpreted as "I don't care 
if my domain is phished" -- so EVERYONE will end up setting the phish 
target bit -- including typo phishers -- and it'll be useless.

The "is this a bank?" decision, or anything like it, should be made far 
outside of SSP.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Thomas A. Fine" <[email-masked]>
Date: Fri, 8 Sep 2006 15:40:14 -0400 (EDT)

Why is anyone going to implement DKIM at all?  What might their
motivation be?

To protect their domain from being spoofed.  The only logical long-term
choice for a domain to achieve this protection is an "all-signed" SSP.

Here's a summary of why:

protection                   SSP/all-signed              user-signing
-------------------------------------------------------------------------
entire domain from spoofing       yes                         no
against phishing                  yes                         sort of
against lhs look-alikes           yes                         no
against rhs look-alikes           no                          no
spam false positive losses        yes                         in part
reduces spam                      eventually                  no

And here's the details:

Protects entire domain from spoofing
If a domain signs every piece of mail it generates, and says publicly
that it does this, then a mechanism is in place for anyone spoofing any
address for this domain to be dropped.  If a domain does not sign
everything, then any unsigned real addresses can be spoofed, and in all
cases non-existent addresses can be spoofed.

Protects against phishing
A phisher can not generate any email from a fully-signed domain.  A
domain that is partly signed is only protected against attacks from
those addresses that it decides to sign.

Protects against lhs look-alikes.
The left-hand-side of the address can not ever be spoofed in a
fully-signed domain, regardless of whether the lhs in question is real
or fake.  With only user-signing, any non-existent address can be
faked.  So if you've protected "accounts", soemone could still spoof
"account" or "acounts" or "accuonts" or "billing" or
"account_administration", and you'd never possible predict everything
in advance.

Protects against rhs look-alikes.
Neither scheme can do this.  If the right-hand-side (the domain) is
a look-alike, then the message can be signed by the look-alike domain.
They can even sign it with extra double-secret protection from
their fake domain and the user will see the gold seal of approval on
the fake look-alike email.

You could make an argument that once all-signed policies become common,
it will become much easier to block mail by domain, which will
allow improved protection against rhs look-alikes.

Eliminates false positive losses from content-based spam filtering.
Once a domain signs everything, all of it's legitimate email may
be accepted by receivers who trust it without content filtering.
If only some addresses are signed, then only those addresses can
be accepted without filtering.

Reduces spam
Every time another domain decides to protect itself by publishing an
all-signed policy, the universe gets marginally worse for spammers,
and marginally better for spam fighters.  Once all-signed policies
become the norm, spammers will be vastly easier to fight, sitting
out on the fringe of the internet, instead of being the everywhere
at once.

What I hope I've showed is that we can get to that point without
relying on the goodness in domain-owners hearts to do this as
a public service.  There are several legitimate and real protections
domain holders will get from an all-signed policy, and only
from an all-signed policy, that make it worth the effort.

"But it's too hard", you say.  You're forcing them to make too many
institutional changes.  First of all I'm not forcing them, I'm
motivating them.  And so what?  They may want us to magically drop in
and solve all their problems with the wave of the wand, but they can't
have that.  When they see the obvious benefits, and the costs
associated with doing nothing, they'll make the changes they need to,
because they always do.

Look at network security.  When cracking systems became a popular
past time, did people throw up their hands and say "we'll never
stop them, so lets do nothing"?  Or did they bite the bullet and
make hard choices that were costly and time-consuming to implement,
and forced annoying changes on everyone?  They did the latter.
The changes were major - users had to stop using telnet and rsh
and rlogin and rexd, and start using ssh, and later VPN.  They
made the adjustment.

Are networks completely safe?  Of course not.  DKIM can never stop all
SPAM.  It can't stop all phishing.  It can't completely fix any
problem.  Locks on buildings don't stop burglary either, but they're
still widely used, and very successful.

"But what happens when my signed email gets out in the world and
gets corrupted and doesn't get delivered and it isn't my fault?"
Then it isn't your fault.  Complain to whoever broke your mail and
make them fix it.  If they won't fix it, complain to the list, and
have them move it to a service that works properly.

"But how can users sign mail from outside of the domain?"  If you trust
them, you can give them a key - it can be their own key, and this will
work without user keys per se, just within the basic DKIM mechanisms.
Or you could give them an account on your system and they could log in
with ssh or VPN.  Or you could set up a secure web interface for
sending mail.  And more I haven't thought of.  When telnet went
away due to poor security, people still found ways to get their work
done.

"But what about SPF -all?  That failed, so all-signed SSP will too,
right?"  Well, when firewalls were new, a lot of them were sold on the
basis that you drop it in your network, turn it on, and you're
protected.  A lot of people fell for that, but they quickly realized it
wasn't true.  The problem with SPF was that it was oversold, and free.
If you paid $10,000 for a firewall that turned out was NOT turnkey, you
get the damn thing to work.  The poeple across the street got theirs to
work.  But SPF was free, so it's easy to give up on.  Especially if
there's no one across the stree with it working perfectly.  So the key
here is to market all-signed SSP honestly, to set real expectations,
and also to demonstrate large-scale working implementations.

"Ok, I'm convinced, but what about user-signing on top of an all-signed
policy?"  Well, amidst all this arguing about user-signing, the only
thing I've seen that comes close to a reasonable argument is the
example of yahoo who signs mail for all of their users, but wants
special protection for [email-masked].  That's a reasonable thing to
want.  Yahoo could alwyas have a different domain for official
business, apart from their vast unwashed masses.  But desiring a
mechanism that says specifically that [email-masked] not just signed
by yahoo, but REALLLY IS YAHOO is still reasonable.

So DKIM is trying to be both a domain signer and a PGP sort of thing
that's better integrated than PGP.  Personally, I see that as a
problem.  domain signing is something that ought to happen at a layer
that's the email equivalent of the transport or session layer in the
OSI network model.  Where genuine user identification belongs more in
the presentation or application layer.  Specifically this is a problem
because for domain keys, I'd like to sign the envelope header, and I'd
like to strip out old signatures and add new ones as needed, which
would alleviate 99% of mailing list issues.  But genuine user
identification has to survive life of message, not just through
end-to-end connection sessions.  As such, it probably doesn't
belong in the headers at all.  So the DK and the IM of DKIM, while
seeming to be extremely similar are actually very different from one
another.  They share alot, but they are not the same.

Maybe that's the source of all the conflicts here.
Maybe it's the fundamental problem with DKIM.

         tom

---

From: wayne <[email-masked]>
Date: Fri, 08 Sep 2006 21:54:10 -0500

> a "No, I really mean it!" modifier?

I've said before that I can see some value, not a huge amount, but
certain some value, in distinguishing between: 

1) I always sign, but I also know that I send email through relays that
   will break the signature.

and

2) I always sign, and I also do not knowingly send email through relays
   that break signatures.

Case 1) is for folks that let their users send email to mailing lists
and such, while case 2) is for folks that are really worried about
phishing and such and are willing to take the necessary steps to that
email with missing/broken signatures can be rejected.

Thinking about it more, I've decided that maybe the clearer
distinction is:

1) I always sign, but I also know that I send email through relays
   that will break the signature.  If you, as a receiver, reject
   legitimate email due to broken/missing signatures, it is your fault
   and I'll place the blame on you.

2) I always sign, but I also do not knowingly send email through
   relays that break signatures.  If you, as a receiver, reject
   legitimate email due to broken/missing signatures, it is my problem
   and you can place the blame on me.

In theory, a receiver of case 1) signing can use the "I sign all"
information, along with other information the receiver knows about the
source of the email (is it a known mailing list? etc.) to make a
reasonable guess about whether a broken/missing signature is a good
spam indicator or not.

In theory, a sender of case 2) can take steps, including no longer
sending email to certain users/domains/relays, to make sure that they
can continue to advertise this stricter sending policy.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Sep 2006 00:09:22 -0700

On Fri, 2006-09-08 at 21:54 -0500, wayne wrote:
> > I guess that the real question is  what's the difference between
> > "I always sign" and "I always sign and I get phished"?
> >
> > sign" is already being written off as likely to be ignored by
> > recipients and that there needs to be a "No, I really mean it!"
> > modifier?
> 
> 
>    that will break the signature.
> 
> and
> 
> 2) I always sign, and I also do not knowingly send email through
>    relays that break signatures.
> 

Well said, but defining these states should probably exclude who is at
blame for mail accepted or blocked.  Not damaging signatures at the MDA
would be most important to ensure protection has not been diminished.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Sep 2006 10:09:03 -0400 (EDT)

>    will break the signature.

This is an assertion about the sender. As such, it is valid within
the context of a sender signing policy.

>    and I'll place the blame on you.

This is an assertion about recipient actions and their consequences.

There is a mistaken perception that that senders have control over
how recipients handle email (whether spoofed or not). A sensible
sender signing policy is limited to assertions about sender actions.

For amusement value, below is my take on some signing policies:
after the first two, everything is either redundant, invalid, or
inconsistent.

	Wietse

0 - No policy (status quo).

1 - All mail from this domain is signed (valid).

2 - Some mail from this domain is signed (equivalent to [0]).

3 - This domain sends no mail (effectively equivalent to [1]).

4 - No-one else can sign my mail (invalid, it attempts to control
    recipient behavior where the recipient is, for example, a
    mailing list, or a user at a DKIM-signing ISP who bounces an
    email message to another site).

5 - Mail from this domain is never signed (inconsistent, it implies
    that a valid signature is invalid; and invalid, as per [4]).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: wayne <[email-masked]>
Date: Sat, 09 Sep 2006 10:26:11 -0500

> sender signing policy is limited to assertions about sender actions.

You are mistaken that I have such a perception.  To be honest, I can't
think of anyone on this list that has that perception, although JohnL,
DaveC and you seem to like to bring up this red herring.

This policy does not say senders have any control over how receivers
handle email, receivers are free to reject or accept the email for any
reason they want.  This is an assertion about what the sender does and
does not do.  In this case, the assertion is that the sender does not
restrict their users to sending stuff to mailing lists and such.

-wayne

---

From: wayne <[email-masked]>
Date: Sat, 09 Sep 2006 10:40:18 -0500

> 3 - This domain sends no mail (effectively equivalent to [1]).

I don't think these two are equivalent.

Again, 3) says what the sender does or not do.  For the receiver, it
is much safer to reject email that has an 2822.From: coming from a
domain that says that they send no email than it is for the much more
generic case of "I sign all email".   This is very similar to being
much safer to reject email from the 2821.MAILFROM or 2821.HELO that
has an SPF record of "v=spf1 -all".  And, note that the DKIM SSP and
the SPF records cover different identities, there is value in having
both.

-wayne

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 Sep 2006 12:32:12 -0400 (EDT)

> DaveC and you seem to like to bring up this red herring.

I speak for myself.

And now to your words:

    "If you, as a receiver, reject legitimate email due to
    broken/missing signatures, it is your fault and I'll place the
    blame on you."

This is an assertion about recipient actions and their consequences.
I call this an attempt to control receiver behavior; you call it
a different shade of grey. Fine. I won't quibble about whether it's
this shade or that, whether something is an absolute demand or
merely a suggestion. It's all part of the same slipperly slope.

A sensible sender signing policy is limited to assertions about
sender actions, and refrains from making statements about recipient
actions and their consequences.

	Wietse

---

From: John Levine <[email-masked]>
Date: 9 Sep 2006 17:19:17 -0000

>I don't think these two are equivalent.

Sigh.  Please provide an operational example where a reciever would
treat mail differently.  To help things along, here are the cases:

a) Unsigned message from domain arrives.  Since there is no valid
signature, there is no relevant key record in the DNS.

b) Signed message from the domain arrives.  Since there is a valid
signature, it was verified using a valid key record from the domain's
DNS.

Straightforward case analysis:

1-a: throw message away, it's forged

3-a: throw message away, it's forged

1-b: accept mail with good signature

3-b: accept mail with good signature, perhaps tell domain owner that his
     SSP is bogus

R's,
John

---

From: John Levine <[email-masked]>
Date: 9 Sep 2006 17:19:17 -0000

R's,
John

---

From: wayne <[email-masked]>
Date: Sat, 09 Sep 2006 12:53:33 -0500

> treat mail differently.  To help things along, here are the cases:

Sigh.  Please read the email you were responding to.  I already gave
the answer:

:                                                 For the receiver, it
: is much safer to reject email that has an 2822.From: coming from a
: domain that says that they send no email than it is for the much more
: generic case of "I sign all email". 

> 1-a: throw message away, it's forged

No, don't throw it away because the lack of a valid signature may well
be due to minor and innocent changes made during transmission.

> 3-a: throw message away, it's forged

Yeah, go ahead and throw it away.

Again, as I said in the post you responded to, this is all about
weighing the risks.  Sure, for some receivers, the differing risks are
irrelevant and it is ok to treat them the same, for others, that is
not the case.

Geez, and I thought you were all hot on not dictating receiver policy.

-wayne

---

From: Michael Thomas <[email-masked]>
Date: Sat, 09 Sep 2006 11:20:18 -0700

>: generic case of "I sign all email". 
Right -- if a message has a broken signature with "I sign everything" 
published,
you always have to wonder whether it was broken in transit if it doesn't 
verify.
If you publish "I never send email", what's to wonder?

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Sep 2006 14:35:11 -0400

> If you publish "I never send email", what's to wonder?
+1

Scott K

---

From: "Thomas A. Fine" <[email-masked]>
Date: Sat, 9 Sep 2006 23:54:14 -0400 (EDT)

wayne wrote:
>> 1-a: throw message away, it's forged  [for "I sign all; bad sig"]
>

Yes, throw it away.  There's no such thing as a minor innocent
change.  If a mail system is misconfigured, then it's mail doesn't
go and it has to fix the problem.  That's how things work now,
why should it change?

Imagine if the people who implemented VPN decided that because
there might be non-standard networking equipment that causes problems,
it should be ok sometimes to establish a VPN connection even when
the authentication didn't work.

>Geez, and I thought you were all hot on not dictating receiver policy.

A domain may not be able to specifically dictate receiving policy.
But an internet standard can certainly try to.

         tom

---

From: John Levine <[email-masked]>
Date: 10 Sep 2006 13:37:50 -0000

>>No, don't throw it away ...

>Yes, throw it away. ...

This lack of consensus on SSP semantics tells me that attempts to
standardize it are extremely premature.  The ASRG is down the hall and
would be thrilled if people wanted to do some experiments and collect
some data to see what the level of signature breakage really is so
they can come back later with rough consensus and running code.

R's,
John

>the authentication didn't work.

If VPNs had to operate through millions of legacy application level
gateways, who knows what they might have decided.  If my recollection
about buggy Windows VPNs are right, they've come pretty close anyway.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 10 Sep 2006 15:43:02 +0100

John Levine wrote:
> standardize it are extremely premature. 

There are clearly some proposed features where standardising would
probably be premature. However, I suspect there are also some core
features of SSP where we will achieve rough consensus for
standardising now. I at least won't be surprised if we end up
with SSP only specifying a very small set of practices but also
being extensible. (We'll need to discuss extensibility requirements
at some point btw.)

But, let's see what happens as we close out the work on ssp-reqs.

Speaking of which, Mike hopes to have a -01 out during the next
week and Barry and I would like the wg to go back to using the
issue tracker and jabber sessions to progress work on that. So,
once reqs-01 is out I'd ask that we make that easier by raising
issues in separate threads, etc. And lastly, please pencil in a
possible jabber session on Thursday, 21st sept. at 1600 here (in
Dublin), 1100 in New York and 0800 on the US west coast, and at
two week intervals thereafter until we get the SSP requirements
dusted. Feel free to comment on this plan to Bary and I offlist -
and we'll try to arrange the logistics etc. to suit as many as
possible.

Cheers,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 10 Sep 2006 07:59:01 -0700

On Sat, 2006-09-09 at 23:54 -0400, Thomas A. Fine wrote:
> > No, don't throw it away because the lack of a valid signature may
> > well be due to minor and innocent changes made during transmission.
> 

A system is not misconfigured that asserts all messages are initially
signed and that non-compliant services are also used. In this case, one
should expect a signature may be damaged or not added by such services.
Sending a message to virtually any mailing list such as this one will
cause messages to be lost when following your advice.  In the case of a
mailing list, the change may not be minor, but at the same time, it is
not nefarious either. 

This attitude confirms John's concerns are valid. : (

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Sep 2006 09:13:25 -0700

> Speaking of which, Mike hopes to have a -01 out during the next

Stephen,

Normally, revisions to working group documents follow explicit 
assessments of rough consensus about changes.

I do not recall seeing this done about SSP, for the changes to be made 
to Mike's doc.

So, what is the basis for Mike's making changes?

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: Sun, 10 Sep 2006 09:27:42 -0700

> So, what is the basis for Mike's making changes?

Well, for better or for worse, I'm just trying to chronical what I've 
been seeing
happen here that seems to rise above repetition from single sources. 
Feel free to
disagree with my take and open an issue so that we  can actually come to 
consensus.
I believe that the plan is to start doing the jabber thing again too.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 10 Sep 2006 15:32:50 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> mailing list, the change may not be minor, but at the same time, it is

Why would you want to send a signed message to a mailing list server that is
a) not DKIM-SSP compliant and b) known to alter the integrity of the
message?

What good as you expecting from this?

All this does is promote the "Cry Wolf" syndrome, harming your own domain
while also putting others at risk of receiving more DKIM junk disguised as
your domain.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 10 Sep 2006 21:33:53 +0100

> I believe that the plan is to start doing the jabber thing again too.

That is the plan, and Mike's efforts to capture things that are likely
to be issues in the tracker should help us to make progress,

S.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 10 Sep 2006 15:00:12 -0700

On Sun, 2006-09-10 at 15:32 -0400, Hector Santos wrote:
> > A system is not misconfigured that asserts all messages are 
> > initially signed and that non-compliant services are also used. In
> > this case, one should expect a signature may be damaged or not added
> > by such services.  Sending a message to virtually any mailing list
> > such as this one will cause messages to be lost when following your
> > advice.  In the case of a mailing list, the change may not be minor,
> > but at the same time, it is not nefarious either.
> 
> a) not DKIM-SSP compliant and 
> b) known to alter the integrity of the message?

Although it may be practical for a domain to ensure all outbound mail is
appropriately signed, it is _not_ practical for a domain to alter the
operations of thousands of mailing-list services without outright
banning their use.  

Stating all email-addresses are initially signed means signature
failures should be limited a subset of domains known to be operating
these non-compliant services.  The operation of these services is
evidenced by a number of signature failures, where such services can be
easily listed.  Messages with failures not from one of these sources
known to cause signature failure may invoke additional analysis.  For
the most part, list administrators appear to promptly handle abuse
issues.

> What good as you expecting from this?

This provides a practical means to deal with signature failures in the
most restrictive fashion possible without expecting the world to
suddenly become DKIM compliant.

> while also putting others at risk of receiving more DKIM junk disguised as

The only alternative option when dealing with you or Thomas would be to
not publish any assertion that all email-addresses are initially signed.
Rather than permitting a practical transitional process, perhaps too
many share your mindset and wish to force everything into becoming
instantly DKIM compliant.  That approach is almost certain to backfire
and may cause policy not to be published, or cause DKIM not to be
deployed. : (

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 10 Sep 2006 20:58:25 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Although it may be practical for a domain to ensure all outbound mail
> is appropriately signed, it is _not_ practical for a domain to alter
> the operations of thousands of mailing-list services without outright
> banning their use.

So I ask again, why would you *blindly* send signed mail to a mailing list
or to just any receiver without having any clue about how they will handle
it?   What do you expect from promusciously sending your precious signed
mail into the wild wild west?  What benefit are you looking for and what you
are expecting?

>> What good are you expecting from this?
>

Huh? You mean you expect failures when you submit signed mail to a mailing
list?  I don't get it.

>> All this does is promote the "Cry Wolf" syndrome, harming your
>> own domain while also putting others at risk of receiving more
>> DKIM junk disguised as your domain.
>
> The only alternative option when dealing with you or Thomas would
> be to not publish any assertion that all email-addresses are
> initially signed.

You mean NEUTRAL operations? Legacy Operations?  If I understand you, you're
right.  Legacy Operations is still the #1 requirement.  But once you step
up,  you better cross the tees, dot the eyes, correctly.  Rest assured,
abuse will not be tolerated. Certainly it turned out to be worst than every
before.

> and may cause policy not to be published, or cause DKIM not to be

You're right.  I expect people with high value domains will avoid DKIM all
together without a dual SIGNER/RECEIVER negotiation concept. They will
quickly realize there is a high risk of exploitation otherwise.

But worst, if anything, the receivers, if they see an increase bombardment
of subjectively determined bad messages with DKIM fingerprints, they might
just use it as a quick and dirty public key detector for filtering the mail.

I already see this now with the junk DomainKeys mail. I can easily see
adding a rule to quick DNS lookup just to check if there is a public key for
mail with DKIM and DKEYS signatures.  No need to bother with the
signature/message hashing verification overhead.

If you want to do this right, when you have to be selective on what you
sign, know who you sending it to and have some clue or expectation about how
its going to be handled. Otherwise, whats the point?  It would be a "Cry
Wolf" waste of time to process DKIM mail without any payoff to it.

In short, half-based solutions don't usually work very well and we have
enough of that already.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 10 Sep 2006 21:44:17 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

> being extensible. (We'll need to discuss extensibility requirements

Hi Stephen,

FWIW, my opinion....

I don't undersstand why we can't just have a mechanism that exposes the
physical possibilities for signatures and let the domains define what is
possible for them?

This is what the basis idea with the two axis concept that quite a few
people agreed with since last year with their own or similar ideas as
follows:

   1P=NEVER | ALWAYS | OPTION    // 1st party
   3P=NEVER | ALWAYS | OPTION    // 3rt party

The only thing that was missing and agreed by all, was a need for a "allow
list" of some kind:

   3PL=options list of 3rd party domains

With these three items, it covers all possible physical signature
fingerprints and combinations. It addresss most, if not all, possible
practical scenarios.

Of course, its quite possible most domains will only zero in on the most
useful policies that makes sense for them, but having this way will limit
domains to the limited behaviors based on the philosophies of just a few
people.

Consider the possibility that if we limit the policies, this might just have
the opposite effect when bad actors specifically create and target scenarios
that that are not covered by the limited SSP standard.

With that said....

In my review of SSP-02, it should all to over all scenarios except for the
3rd party Allow list.   SSP-02 leaves this open-ended and I feel that is a
mistake. It needs to be defined.

Here is a table I produced showing how it covers all possible policies
(except the 3rd party list)

EXPECTATION  SSP-02      DKIM-BASE         RESULT
-----------  ----------  ---------         ------
OPTIONAL     p=UNKNOWN   NO SIGNATURE      CONSISTENT
                         OP PASS           CONSISTENT
                         OP FAIL           SUSPICIOUS/IGNORE
                         OP FAIL-NOKEY     SUSPICIOUS
                         3P PASS           ACCEPT
                         3P FAIL           SUSPICIOUS/IGNORE
                         3P FAIL-NOKEY     SUSPICIOUS

NO MAIL      p=STRICT    NO SIGNATURE      SUSPICIOUS
                         OP PASS           INCONSISTENT*
                         OP FAIL           SUSPICIOUS
                         OP FAIL-NOKEY     SUSPICIOUS
                         3P PASS           SUSPICIOUS
                         3P FAIL           SUSPICIOUS
                         3P FAIL-NOKEY     SUSPICIOUS

NEVER SIGN   p=STRICT    NO SIGNATURE      SUSPICIOUS
                         OP PASS           INCONSISTENT*
                         OP FAIL           SUSPICIOUS
                         OP FAIL-NOKEY     SUSPICIOUS
                         3P PASS           SUSPICIOUS
                         3P FAIL           SUSPICIOUS
                         3P FAIL-NOKEY     SUSPICIOUS

SIGNED       p=STRICT    NO SIGNATURE      SUSPICIOUS
                         OP PASS           CONSISTENT
                         OP FAIL           SUSPICIOUS/IGNORE
                         OP FAIL-NOKEY     SUSPICIOUS
                         3P PASS           SUSPICIOUS
                         3P FAIL           SUSPICIOUS
                         3P FAIL-NOKEY     SUSPICIOUS

SIGNED       p=ALL       NO SIGNATURE      SUSPICIOUS
                         OP PASS           CONSISTENT
                         OP FAIL           SUSPICIOUS/IGNORE
                         OP FAIL-NOKEY     SUSPICIOUS
                         3P PASS           UNKNOWN
                         3P FAIL           UNKNOWN
                         3P FAIL-NOKEY     SUSPICIOUS

* Should not happen

As you can see, some of the expected policies can be folded under the
p=strict policy, in particular NO MAIL and NEVER SIGN can be folded by
creating a NULL public key.  The only issue here is that you need TWO DNS
lookups to accomplish this. One to get the p=strict policy and one to find a
null public key.

In short, I think Jim did a great job with SSP-02, but it needs to now focus
on the 3rd party list which Jim calls "Verifier Acceptable 3rd party" in
section 2.10:

2.10.  Verifier Acceptable Third-Party Signature

   A Verifier Acceptable Third-Party Signature is a Third-Party
   Signature that the Verifier is willing to accept as meaningful for
   the message under consideration.  The Verifier may use any criteria
   it deems appropriate for making this determination.

You can't leave this open-ended.  There is needs to be a definition defined
to the domain responsible for all this.  I think once this is done, we are
basically there.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 10 Sep 2006 22:43:56 -0700

> mail into the wild wild west?  What benefit are you looking for and what you

An administrator may make an assertion all email-addresses within the
domain are initially signed, AND only compliant services are used.
Making the first assertion, the administrator needs to ensure users
utilize specific outbound services.  This added requirement should not
limit where messages are eventually sent.  

Making the second assertion will impact an ability to participate in a
mailing-list.  This second assertion might be desired to curb spoofing
by limiting acceptance of invalid signatures as an alternative to
reliance upon retained email-address annotations.  Retained
email-address annotation also prevents look-alike attacks however, and
provides far better protection.  This second assertion might be seen as
just a stop-gap measure.

Indivdual users may decide to participate in a mailing-list where a
signature is likely damaged.  The eventual recipients are the
mailing-list subscribers, and the situation where signatures are damaged
will not change anytime soon.  When the first assertion is made,
email-addresses with invalid signatures could be limited to sources
known to damage signatures, if limited at all. 

You are suggesting that by signing a message, it should only be accepted
when the signature verifies.  This will greatly discourage deployment of
DKIM, let alone publishing policy that all messages are initially
signed.  Consider that DKIM annotations based upon retained
email-addresses offers superior anti-spoofing protection without a need
to block messages with invalid signatures or to selective sign messages.

> > This provides a practical means to deal with signature failures in
> > the most restrictive fashion possible without expecting the world to
> Huh? You mean you expect failures when you submit signed mail to a
> mailing list?  I don't get it.

Absolutely.  How do you expect initial signatures to survive the typical
formating and flattening, in addition to subject line changes and
unsubscribe and ad information normally appended or prefixed to the
message body?  Any effort to accommodate message modifications only
invites abuse that could now come from anywhere, rather than known
services.

> You mean NEUTRAL operations? Legacy Operations?  If I understand you,
> you're right.  Legacy Operations is still the #1 requirement.  But
> once you step up, you better cross the tees, dot the eyes, correctly.
> Rest assured, abuse will not be tolerated. Certainly it turned out to
> be worst than every before.

A bad actor can sign using DKIM and publish any highly restrictive
policy they wish.  Navigating policy aimed at blocking messages will
prove most difficult for legitimate users and administrators.  The bad
actor will keep turning the knob until their messages are accepted.  

> You're right.  I expect people with high value domains will avoid DKIM
> all together without a dual SIGNER/RECEIVER negotiation concept. They
> will quickly realize there is a high risk of exploitation otherwise.

Exactly how would DKIM be exploited?  An invalid signature should offer
no advantage.

> But worst, if anything, the receivers, if they see an increase
> bombardment of subjectively determined bad messages with DKIM
> fingerprints, they might just use it as a quick and dirty public key
> detector for filtering the mail.

While this approach might be employed in an attempt to curb replay
abuse, this will also need to accommodate the number of subscribers in
various mailing-lists.  List that identify mail-lists should be easy to
compose.  Perhaps bulk senders might be forced into using unqiue
signatures for each subscriber. : (

> adding a rule to quick DNS lookup just to check if there is a public
> key for mail with DKIM and DKEYS signatures.  No need to bother with
> the signature/message hashing verification overhead.

This would leave your domain exposed to abuse once that strategy becomes
apparent to the bad actors.

> If you want to do this right, when you have to be selective on what
> you sign, know who you sending it to and have some clue or expectation
> about how its going to be handled. Otherwise, whats the point?  It
> would be a "Cry Wolf" waste of time to process DKIM mail without any
> payoff to it.

While that strategy might be considered plausible, it seems unlikely to
find concensus.  SMTP is a store and forward system.  There is no way to
know where the finial destination of the message might be, and what
might happen to the message in transit.  DKIM should be robust and able
to deal with damaged signatures.  The use of retained email-address
annotation ensures protection is not lost as a result of signature
damage.

> In short, half-based solutions don't usually work very well and we
> have enough of that already.

There should be a strategy that makes sense and that is easy to
administer.

-Doug

---

From: "Thomas A. Fine" <[email-masked]>
Date: Mon, 11 Sep 2006 10:43:41 -0400 (EDT)

>    that a valid signature is invalid; and invalid, as per [4]).

This analysis is correct (strictly speaking) given the current description
of how things work.

I think this is the source of confusion - you can check the certificate
without checking the policy (or perhaps, you're required to check
the certificate first).  The EXISTENCE of a certificate is taken as
an implied policy that this particular message is supposed to be signed.

The more complicated arrangements some people are suggesting here will
only work if you know the policy before you look for a certificate.
Now I could argue that we should be doing it this way, but I'm
not going to do that right now.

Even in the context of the current specification, it's a simple matter
of optimization that implementations WILL be cacheing the policy lookups
for a short period of time.  IF a receiver has a policy cached, and
IF we have the more complex policy descriptions, it may be possible in
some cases to bypass the certificate lookup and subsequent attempt
at verification, which can be a signicant savings, and one could argue
that it can prevent denial of service attacks from a bad actor.

So even without policy first in the spec, we will often have policy
available upon receipt of a message.

         tom

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Sep 2006 11:22:04 -0700

> they can come back later with rough consensus and running code.
The recent discussion on the list has rambled a great deal, and involved
a relatively small number of people, and mostly under the misleading
subject line "user level ssp" (which to your credit you changed when
making the above comment).  Judging this as lack of consensus strikes me
as extremely premature.

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 03:52:45 +0200

Douglas Otis wrote:

>> 1) I always sign, but I also know that I send email through
>>    relays that will break the signature.  If you, as a
>>    receiver, reject legitimate email due to broken/missing
>>    signatures, it is your fault and I'll place the blame on
>>    you.
[...]
>> In theory, a receiver of case 1) signing can use the "I sign
>> all" information, along with other information the receiver
>> knows about the source of the email (is it a known mailing
>> list? etc.) to make a reasonable guess about whether a
>> broken/missing signature is a good spam indicator or not.
[...]
> defining these states should probably exclude who is at
> blame for mail accepted or blocked.

+1  Receivers might not know some mailing-lists, consider known
lists as bad, etc.  For receivers with an empty white-list case
1 and 2 are very similar.  And rejecting is better than "tag as
suspicious" (which in essence means "let the users delete this
unread")

> Not damaging signatures at the MDA would be most important

A wannabe-MDA damaging signatures, stripping header fields, or
not reporting the Return-Path is IMHO a gateway to lala-land.

Frank