Subject: Re: [ietf-dkim] NO DKIM "POLICY"

From: Franck Martin <[email-masked]>
Date: Sat, 21 Feb 2009 10:45:34 +1200 (ANAT)

Any way to tell someone its signature is used in third party signing? 

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]> 
To: "Franck Martin" <[email-masked]> 
Cc: [email-masked], "Hector Santos" <[email-masked]> 
Sent: Saturday, 21 February, 2009 10:20:39 AM (GMT+1200) Auto-Detected 
Subject: Re: [ietf-dkim] NO DKIM "POLICY" 

On Feb 20, 2009, at 1:58 PM, Franck Martin wrote: 

but it can come from @example.com signed by @test.com 

This could be described a third-party signature, where test.com should not be considered authoritative for example.com, just as ads.example.com should not be. While test.com may allow acceptance of example.com's email, its signature should not directly assure recipients that use of the example.com domain is not being spoofed. Socially engineered attacks can easily acquire a signature from an otherwise reputable domain. 

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Feb 2009 18:59:28 -0500

> Any way to tell someone its signature is used in third party signing? 

AFAIK, not in a standard fashion

As Doug pointed out, you can detect that it appears to be 3rd party, 
but the long debated issue has been how to determine if the
3rd party was "authorized" to sign for the 1st party domain (Author 
Domain, From:)

This was the original DKIM idea - to include POLICY ideas like this.

DKIM was then separated as DKIM-BASE and SSP. SSP had policies like:

    I don't send mail
    I always sign
    I sometimes sign
    I allow 3rd party signers.

I have a good diagram that illustrates the logic flow when SSP policy 
was considered:

   http://www.winserver.com/public/ssp-old/ssp.htm

In short, verifiers could do policy DNS lookup and check the "o=" tag:

    o=.  NEVER  (no mail expected)
    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd aparty allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=^  USER

If it was o=? or o=!, then that means no 3rd parties signing was 
expecting. If it was o=~ or o=-, then 3rd party was allowed, etc.

But unfortunately, the January 2008 blockbuster shock of the year, out 
of the blue, SSP was stripped down to what we have today ADSP which 
for the most part only has:

    dkim=unknown      The domain might sign some or all email.
    dkim=all          I always sign, only me. "Don't delete?"
    dkim=discardable  same as all "but you can delete?"

Maybe someone can confirm that, but I'm sure sure that is basically 
all it offers.

To answer your question - not possible.

The topic here "NO DKIM" was trying to redeem something of the based 
spec hopefully, the NULL PUBLIC KEY and that idea came from the author 
of DKIM.  A customer of ours got noticed from one of their vendors 
about DKIM signing and wanted to know what can they do to isolate it.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: John Levine <[email-masked]>
Date: 21 Feb 2009 14:53:45 -0000

>Any way to tell someone its signature is used in third party signing? 

No.  See the list archives where this issue was beaten to death
several times.

Remember that invalid signatures are ignored, and signers are already
aware of all the valid signatures they've applied.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Feb 2009 10:35:03 -0500

> aware of all the valid signatures they've applied.

Well, according what I seen by the GMAIL verifier, it is discarding 
mail with invalid signatures.

I confirmed this 6 times last night with one message recent 6 times. 
Four of the six were slightly modify each time to force an integrity 
error. These were accepted by GMAIL's SMTP server but silently 
discarded (never posted). The other two were the same original DKIM 
signed message but with the DKIM-Signature header cut out.  The two 
messages was accepted and immediately posted.

As long as the original DKIM-Signature remained, the message was not 
delivered.

I guess at least 1 big system is not listening to the Invalid 
Signature Ignorance DKIM policy.

Either they are right and saved the day or they were wrong and bad 
mail was unexpectedly lost.  Take the DKIM-Signature out and mail
is delivered.

Again, all I did was essentially replay a valid DKIM signed message 
(according the original AR that indicated a DKIM pass) by slightly 
modifying its content and/or headers.  Gmail accepted the mail, but it 
was not delivered.  I took out the DKIM-Signature and poof! It made it 
thru.  That indicates they are not following this ignore invalid 
signature rule.

-- 
Sincerely

Hector Santos

---

From: John Levine <[email-masked]>
Date: 21 Feb 2009 20:00:45 -0000

> mail with invalid signatures.

I sent a message to my gmail account with a broken signature, and
gmail noted the bad signature and delivered it just fine.  Evidently
there's something else wrong with your mail.

Authentication-Results: mx.google.com; spf=pass (google.com: domain of prvs=02964ee325=[email-masked] designates 208.31.42.53 as permitted sender) smtp.mail=prvs=02964ee325=[email-masked]; dkim=hardfail header.i=[email-masked]

Anyway, even if a large ISP were mishandling DKIM signatures, that
would be a reason to encourage the ISP to fix their DKIM processing,
not to change the spec.

You've made it abundantly clear that you'd like lots of unenforceable
rules about who can do what to mail you send them.  But that's not
what DKIM does, so please stop.

R's,
John

---

From: HLS <[email-masked]>
Date: Sat, 21 Feb 2009 15:50:25 -0500

I am not looking for unenforceable rules. I am looking for consistency and
there is none.  All this has to make sense before offering it to our SMTP
customers.

Just consider what is a verifier or a "assessor" to do with that hard
failure you got.

Is this an indication of an preexisting signature?  As it is, there is a
recording of the failure and that AR may be input to another process logic.
   It has nothing to do with enforcement but rather consistency. It doesn't
make sense to tell another layer "there is no signature", when in fact there
was one, as recorded by the AR. As you can see,  the AR can be used as input
for some reputation service as well.

So maybe there should be a consideration to clarify in this Errata what
exactly the "Broken Signature to No Signature" really means from an
implementation standpoint. Is that too much to ask?

The mail I sent was a replay modification of a previous valid signature
message sent right back to GMAIL.   Only when I removed the DKIM-Signature
header did it finally post it.

-- 
hls

On Sat, Feb 21, 2009 at 3:00 PM, John Levine <[email-masked]> wrote:

> Authentication-Results: mx.google.com; spf=pass (google.com: domain of
> prvs=02964ee325=[email-masked] designates 208.31.42.53 as permitted
> sender) smtp.mail=prvs=02964ee325=[email-masked]; dkim=hardfail header.i=
> [email-masked]
>

-- 
hls

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 21 Feb 2009 15:48:40 -0500

>   Any way to tell someone its signature is used in third party signing?

I've been working on something to do just that. Or at least a way to
say such signatures are allowed. My understanding of a "third party"
signature is an authenticated domain that doesn't match RFC 5322.From.
It always bothered me that some may treat 1st party signatures (where
the authenticated domain does match RFC 5322.From) as more trustworthy
than 3rd party signatures. Personally I think that there is no need to
treat 1st and 3rd differently.

So, I've come up with this way to see if the "3rd party" is blessed by
the "1st party":

1) query for the authenticated domain against the 1st party's domain
record using the "Vouch by Reference" protocol.

2) if the domain is listed, then the "3rd party" domain shouldn't be
considered as such.

Here's a hopefully obvious example:

From: [email-masked]
DKIM-Signature: ... d=aol.com ...

querying for aol.com in aim.com's domain space (via VBR) would return a
result.

We have a rough spec here:
http://mipassoc.org/affil/specs/draft-macdonald-affiliated-nameslist-00-04dc.html

Today we use VBR, but my co-author and I are thinking that we'd
probably wouldn't even need that once things are ironed out.

-- 
Jeff Macdonald
[email-masked]

---

From: "Olivier MJ Crepin-Leblond" <[email-masked]>
Date: Sun, 22 Feb 2009 00:34:21 +0100

> there's something else wrong with your mail.

You're right: Gmail's probably "whitelisting" the emails with correct 
signature whilst pushing the ones with broken signature through their 
spam filters. If the filters don't detect Spam, gmail will deliver the 
email.

O.

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Feb 2009 04:06:18 -0500

> spam filters. If the filters don't detect Spam, gmail will deliver the 

That would make sense, if indeed the message were spam hence 
explaining why it wasn't finally posted.  But that is not what was 
observed.

Look, the lesson here is that DKIM does nothing for legacy mail (Mail 
without DKIM signatures).

There is no protection unless the implementator ignores the "Broken 
Signature Is No Signature" inherent policy in DKIM.

The failed signature will be recorded and passed to classification 
routines as GMAIL has shown.

If John believes that is an implementator fault, not the spec. Well, I 
see it as the spec had it wrong.

I believe this mandate was born from the original original DKIM + SSP 
framework, where SSP had policies to deal with this.  Hence if a 
broken signature was promoted to no signature status, the "Always 
Sign" policy would handle this case.

But without SSP, the semantics are no longer valid.

In fact, I would suggest there are conflicts with this 4.2 statement 
with what is described in 6.2 and 6.3

4.2.  Interpretation

    ...
    Verifiers SHOULD ignore failed signatures as though they were not
    present in the message.  Verifiers SHOULD continue to check
    signatures until a signature successfully verifies to the
    satisfaction of the verifier.  To limit potential denial-of-service
    attacks, verifiers MAY limit the total number of signatures they
    will attempt to verify.

6.2.  Communicate Verification Results

    Verifiers wishing to communicate the results of verification to
    other parts of the mail system may do so in whatever manner they
    see fit.

6.3 Interpret Results/Apply Local Policy

    ...

    While the symptoms of a failed verification are obvious -- the
    signature doesn't verify -- establishing the exact cause can be
    more difficult.  If a selector cannot be found, is that because the
    selector has been removed, or was the value changed somehow in
    transit?  If the signature line is missing, is that because it was
    never there, or was it removed by an overzealous filter?  For
    diagnostic purposes, the exact reason why the verification fails
    SHOULD be made available to the policy module and possibly recorded
    in the system logs.  If the email cannot be verified, then it
    SHOULD  be rendered the same as all unverified email regardless of
    whether or not it looks like it was signed.

4.2 only make sense if POLICY was still in place as an available 
technology as it was when DKIM was first written.

-- 
Sincerely

Hector Santos