Subject: Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 01 Mar 2007 13:06:54 -0000

On Wed, 28 Feb 2007 13:21:55 -0000, Hector Santos <[email-masked]>  
wrote:
>
> There are three basic outcomes with a message:
>
>     VALID SIGNATURE
>     INVALID SIGNATURE
>     NO SIGNATURE

No, there are four basic outcomes with a message. You omitted

       UNVERIFIABLE SIGNATURE

which just happens to be the one that this thread is all about.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Thu, 1 Mar 2007 08:44:21 -0500 (EST)

> which just happens to be the one that this thread is all about.

On a friendly internet with only cooperating parties, this might
make sense.  But the world has changed. With today's internet it
would be a fundamental mistake to make more distinctions than:

    the signature was verified
    other

If the verifier gives different treatments to different types of
"other", then the bad guys will exploit the verifier's behavior.

The solution to the problem is not to complicate the protocol, but
to avoid the mistake of giving different treatments to different
types of "other".

	Wietse

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 09:28:56 -0500

+1

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wietse Venema
Sent: Thursday, March 01, 2007 8:44 AM
To: Charles Lindsey
Cc: DKIM
Subject: Re: Additional lookups (was Re: [ietf-dkim] Re: 1368
straw-poll)

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Mar 2007 07:07:24 -0800

+1.

-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 1 Mar 2007 08:42:28 -0800

On Mar 1, 2007, at 5:06 AM, Charles Lindsey wrote:

> On Wed, 28 Feb 2007 13:21:55 -0000, Hector Santos  
> <[email-masked]> wrote:
>>

If it's not verifiable, it's not a signature. (The same applies to  
"invalid signature", of course).

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Thu, 1 Mar 2007 08:44:03 -0800

+1.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 13:26:44 -0500

> which just happens to be the one that this thread is all about.

All invalid signatures are unverifiable. That is what makes them invalid.

The whole problem here is a prime example of cliches:

     "Beating a dead horse"
     "Deja vu"
     "soup of the day"

etc.

--
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Mar 2007 20:53:21 +0100

> If it's not verifiable, it's not a signature. (The same applies
> to "invalid signature", of course).

Probably Charles means "unverifiable == verifier doesn't know how
to check it (it could be valid or invalid otherwise)", and uses
"invalid" for "it's definitely wrong with the specified algorithm".

The folks supporting to list used algorithms in the SSP apparently
think that receivers could care about this nuance.  And the folks
opposing that idea note that spammers would try to abuse this info.

Frank

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 1 Mar 2007 15:46:38 -0500

+1

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 01 Mar 2007 16:59:04 -0600

+1

This is absolutely correct.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 01 Mar 2007 17:07:44 -0600

> think that receivers could care about this nuance.

In my view, they won't care.  They can't care.  In fact, they *dare not* 
care.  Knowing that a signature "might have verified if only I knew how 
to do so" is worthless from a practical perspective.

Arvel

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Mar 2007 15:47:14 -0800

On Mar 1, 2007, at 3:07 PM, Arvel Hathcock wrote:

> In my view, they won't care.  They can't care.  In fact, they *dare  
> not* care.  Knowing that a signature "might have verified if only I  
> knew how to do so" is worthless from a practical perspective.

1) When a signer offers multiple signatures, the verifier should  
select their preferred signature.

2) When a signer indicates that an algorithm within the a signature  
has been deprecated, then the verifier should expect the specified  
signature to be available.

3) When the specified alternative signature does not exist, the  
deprecated signature should be considered invalid.

Verifiers desiring the strongest protection should be able to detect  
when an optional signature has been removed.  This protection ensures  
a graceful transition regardless of the severity of the possible  
threat.  Ensuring a graceful transition is a practical  
consideration.  Dare to care.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 20:12:42 -0500

> "other", then the bad guys will exploit the verifier's behavior.

Applying equal treatment should be done across the board, the valid and 
invalid, not just for the so called "elite" messages.

It is with the exceptions and relaxed provisions where exploitation will 
take place, the FSUSP (FAILED SIGNATURE UNSIGNED STATUS PROMOTION) is 
one of them.

Of course, this was pointed out to the yahoo guy in a similar thread 
last year where verifiers might give different "reputation" treatments 
to valid DKIM messages. This will also have the same exploitation factor 
-  XYZ domain signs up with ABC Reputation house,  XYZ domain is now 
spoofed everywhere else due it is "credentials."

--
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Mar 2007 17:52:06 -0800

On Mar 1, 2007, at 5:12 PM, Hector Santos wrote:

> Of course, this was pointed out to the yahoo guy in a similar  
> thread last year where verifiers might give different "reputation"  
> treatments to valid DKIM messages. This will also have the same  
> exploitation factor -  XYZ domain signs up with ABC Reputation  
> house,  XYZ domain is now spoofed everywhere else due it is  
> "credentials."

When millions of new domains are acquired at no cost every day, even  
finding a valid signature is not likely to hold much value.  In  
addition, even where providers such as Yahoo restrict the volume of  
messages from each account, nothing prevents these messages from  
being relayed well beyond these constraints.

By allowing a signer policy that can associate various originating  
domains with that of the signing domain, permit the detection of  
possible replay abuse and DSN MailFrom spoofing.  Few messages being  
returned will verify.  "Does this MailFrom belong with this signing  
domain?" could be answered by a signing policy.  Such would be a  
feature of the DOSP draft.  I admit this draft is well over the top,  
but it does provide a means to answer these basic questions.

Rejecting messages carrying a particular From header will not provide  
substantial protection.  Taken to the extreme, this approach is  
likely make things worse.  DKIM can help curb abuse when there is a  
means to associate the signing domain with different originating  
domains.  I am not a fan of the oft heard suggestion that everyone  
should delegate their domain or share their private key, to say the  
least.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Thu, 1 Mar 2007 21:00:34 -0500 (EST)

> take place, the FSUSP (FAILED SIGNATURE UNSIGNED STATUS PROMOTION) is 

Perhaps I wasn't clear enough.

When a DKIM verifier gives unequal treatment to any of the following:

- no signature
- broken signature
- unsupported signature
- other failure

Then the bad guys will send their forged mail in the way that receives
the most favorable treatment.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 21:01:32 -0500

> "invalid" for "it's definitely wrong with the specified algorithm".

The point is that this is a only a reason for the invalid state.  There 
could be many reasons:

   - key is missing (i.e, DNS failed)
   - expired
   - body hash failed (pieces are available, it just fails)
   - signature failed (pieces are available, it just fails), and
   - unknown hash

etc. What needs to be done is a guideline for verifier handling for a 
list of very possible and probable encounters.

The specification solution today is what I call FSUSP (Failed Signature 
Unsigned Status Promotion) and my point FSUSP is not the same as a real 
NO SIGNATURE message.

To me, a NO SIGNATURE should have one trigger - check the SSP to see if 
its has to be signed.

To me, FSUSP concerns me a lot and I believe it can be very damaging to 
DKIM adoption if FSUSP creates avalance of mail abuse.

> opposing that idea note that spammers would try to abuse this info.

Any advertised information can be exploited, but if it is or not 
advertised, for the VERIFIER (and SIGNER) the problem will still exist.

To me, the VERIFICATION process is the most important part, yet, I am 
not interested in making it very heavy loaded with useless processing.
Yet we need to understand what are the short circuits of the protocol. 
To find them, you list your possible error conditions (or conditions 
that create a valid/invalid state) and find how to eliminate the obvious 
- Query Dissemination process.

In this case, the most probable scenario is a signature that validates 
which means the key existed.  If the signer did not want that, I can't 
see any other way but to nullify the key.

I can't see how the verifier can make an "exception" to the scenario 
where the signer has a NEW method (advertised or not) but the current 
message has some other older method and the key was pulled. If it was 
not pulled, well, there is really nothing you can do about that.

--
HLS

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Mar 2007 18:21:23 -0800

> the most favorable treatment.
Correct. +1. Bueno.

I think that what people need to keep completely separate is that
forensic categorization is NOT the same as what an automaton
should be programmed on. It's fine to mine all of these nuances
to look for trends, etc, but it requires judgment and some amount
of risk. A dumb automaton is usually not this informed, and we
definitely do not want to promote the idea that you naively use
those clues as if they were not gameable.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 21:17:55 -0500

> the most favorable treatment.

You kidding me?

Of course its clear, I wrote a IEFT DRAFT on the subject:

http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html

I've been the #1 vocal point on FAILURE HANDLING.  What you guys wish to
do is ignore failure and only look for the "good needle in the haystack" 
(small percentage of valid DKIM messages) and that my friend is the 
mirror image of the same exploitation you are know concern about.

What is surprising is that you finally coming around to the idea that
having an non-official way of failure handling is a PROBLEM.  Oye Vey!

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 21:38:56 -0500

Michael Thomas wrote:
>>> Applying equal treatment should be done across the board, the valid 
>>> and invalid, not just for the so called "elite" messages.
>>>
>>> It is with the exceptions and relaxed provisions where exploitation 
>>> will take place, the FSUSP (FAILED SIGNATURE UNSIGNED STATUS 
>>> PROMOTION) is one of them.
>>>     
>>

Michael, process automation is my expertise. As a chemical engineer, I 
am highly trained to look a total system integration for cause and effects.

But thats neither here or there,  this is all quite simple.

Your have a SMTP Appliance product in the market. You have thousands, if 
not millions of customers using your SMTP Appliance product.

I find it highly unprobable, near on the ridiculous, that this product 
is going to IGNORE failures with their new DKIM processing.

If you ignore it, then what you have done is simply promote legacy 
operations with the bad guys - they don't have to sign at all.  If you 
tell me that you have offer an HELPER system (reputation or otherwise), 
then you are not ignoring it and unless everyone has the same reputation 
system and/or SMTP Appliance box,  you will be treating it differently.

Thanks

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 1 Mar 2007 21:46:02 -0500

> the most favorable treatment.

Absolutely +1.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 Mar 2007 22:29:16 -0500

Douglas Otis wrote:
>> to valid DKIM messages. This will also have the same exploitation 
>> factor -  XYZ domain signs up with ABC Reputation house,  XYZ domain 
>> is now spoofed everywhere else due it is "credentials."
> 
> finding a valid signature is not likely to hold much value.  

If we are on the same wavelength, with the premise a node will process a 
high volume of bad domains, overhead will be tremendous, efficiency low 
in looking for the small percentage "good needle in the haystack" in the 
avalanche of mail.  It probably won't be worth the effort.

Just keep in mind that these MILLION DOMAINS do not have to waste time 
with any kind of DKIM consideration since ALL systems must operate in 
legacy mode anyway and since FSUSP is a (unfortunate) part of the 
DKIM-BASE spec, to me, that just tells bad guys they don't have to worry 
too much about cracking anyone keys - just fake it.  Just make it look 
like it has some "high profile" status in relationship to contemporary 
non-existence profiles.

> In 
> messages from each account, nothing prevents these messages from being 
> relayed well beyond these constraints.

Now I am a different wavelength <g>

> domain?" could be answered by a signing policy.  Such would be a feature 
> of the DOSP draft.  I admit this draft is well over the top, but it does 
> provide a means to answer these basic questions.

Well, maybe, but going back to my paragraph about, that thread was about 
the same concern Wieste suddenly discovered.

For failure, the DKIM-BASE solution is FSUSP but since it allows for 
local policy, I highly doubt FSUSP will be tolerated, especially when as 
systems learn how abusive FSUSP can be in a high volume of bad mail.

For success, there is NO standard handling. We have ideas, such as DAC. 
But because there is no standard for handling success, there will be 
different treatments at the verifiers and this is just as exploitable as 
the failures.

That was my point.

I'm a very practical engineer, and in my view, SSP offers a MINIMAL set 
of instructions to eliminating the (unexpected) obvious.

> substantial protection.  Taken to the extreme, this approach is likely 
> make things worse.  DKIM can help curb abuse when there is a means to 
> associate the signing domain with different originating domains.  I am 
> not a fan of the oft heard suggestion that everyone should delegate 
> their domain or share their private key, to say the least.

To me, successful process automations are based on how good it can 
detect failure or deviations from the norm (expected protocol behavior). 
When you have provisions to be flexible with failure, then it makes the 
process unpredictable.  So whatever you admins want to do just has to 
make sense from a protocol and automation standpoint.

--
HLS

---

From: John Levine <[email-masked]>
Date: 2 Mar 2007 04:16:55 -0000

+1

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Mar 2007 21:07:23 -0800

> avalanche of mail.  It probably won't be worth the effort.

Only recognized domains should be verified.  Why verify when there is
nothing known about the domain?  Why attempt to send meaningless results
to message consumers?  Even worse, verification gives valuable
information to bad actors.  Unless the domain is trusted, do nothing and
say nothing.

> like it has some "high profile" status in relationship to contemporary 

DKIM is good for high profile domains that might otherwise be filtered
out along with millions of spoofing attempts.  DKIM can dramatically
reduce false positive rates. For this, signer policy does not help, as
not signing is even more likely to cause their messages to be filtered
regardless of exceptions made in the signer policy.  Any exception is
sure to be abused.

> systems learn how abusive FSUSP can be in a high volume of bad mail.

Especially when it requires the entire message be received, processed,
which then specifically identifies the message status.

> different treatments at the verifiers and this is just as exploitable as 

How anyone can be certain who is messing up with DKIM?  When you hear
"Someone else must have sent that message." what can you say?  You
created the content, therefore you're guilty of sending unsolicited
messages?  Would standing firm be worth the multi-million dollar
liabilities?
 
> of instructions to eliminating the (unexpected) obvious.

DKIM can help ensure DSNs are returned.  DKIM can ensure any abuse
feedback goes to those responsible for transmitting. (Provided domain
delegation or private key exchange does not become popular.)  Why not
allow email-address domain owners to authorize who is signing on their
behalf?  Their providers could even sign using unique domains when
customer isolation is important.

> make sense from a protocol and automation standpoint.

When it comes to email, we are dealing with the fog of war.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 02 Mar 2007 10:54:11 -0000

> "other", then the bad guys will exploit the verifier's behavior.

And how do you stop verifiers doing that?

Verifiers will do as they think fit (i.e. what their clients will pay  
for), whatever our standards say. If some likely (though deprecated)  
verifier behaviour leads to exploits by the Bad Guys, and there is an easy  
way to counter the exploit (e.g. by clearer information in the SSP), then  
it would be wise to dopt it.

"Defence in depth" is the term, I believe.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 02 Mar 2007 10:57:07 -0000

> "invalid" for "it's definitely wrong with the specified algorithm".

Correct.
> opposing that idea note that spammers would try to abuse this info.

Eh? This info is provided to counter a possible exploit. Nobody has yet  
suggested that this extra info will open the way to yet further exploits.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 02 Mar 2007 16:24:05 +0100

> Eh? This info is provided to counter a possible exploit. Nobody has
> yet suggested that this extra info will open the way to yet further
> exploits.

I'm too lazy to dig through the last 250 or so messages to find the
source (probably posted by John or Dave), but IIRC the idea was this:

A signer publishes to support a new algorithm "rot13".  If spammers
happen to know that certain receivers don't support "rot13", they
can forge (invalid) "rot13" signatures in phishes to these receivers.

For "rot13" insert something serious, e.g. something not affected by
<https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=795>

Frank

---

From: [email-masked] (Wietse Venema)
Date: Fri, 2 Mar 2007 11:22:22 -0500 (EST)

> And how do you stop verifiers doing that?

There is no cure for stupidity, but I can try to educate.

> "Defence in depth" is the term, I believe.

SSP is not a cure for exploitable verifiers. 

"Wrong solution for the wrong problem" is the term, I believe.

	Wietse