ietf-mailsig
[Top] [All Lists]

Re: DKIM Verification Algorithm

2005-08-05 03:46:50
The behavior of the testing flag isn't very well defined, but is usually considered to be something like, "I'm just testing, so if verification fails, that may explain it." So if the verification succeeds, the testing status of the SSP record is probably irrelevant. Of course, it's not irrelevant if we have a NONE signing policy, but my opinion remains that we can resolve that with EXCLUSIVE and save the policy lookup if the verification succeeds.

-Jim

Graham Finlayson wrote:

Jim,

I am a little confused than of the distinction between testing DKIM and
testing Signing Policy. Can someone have a key record that is not being
tested, but an SSP record that is being tested? Does this make sense,
and what affect will this have on the matrix below?

Graham

-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com] Sent: Thursday, August 04, 2005 4:20 PM
To: Graham Finlayson
Cc: IETF-MAILSIG
Subject: Re: DKIM Verification Algorithm

Graham,

The key record also has a t= flag.  Will that do?

-Jim

Graham Finlayson wrote:
        Jim,
        
I also would like to not have to do this additional SSP DNS lookup where possible. Unfortunately, I think your optimization will not work due to the t= flag that can be present in the SSP. This could be overcome if the testing information could be moved into
        the DKIM-Signature header field.
        
        Graham
        
                -----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim Fenton
                Sent: Thursday, August 04, 2005 9:06 AM
                To: william(at)elan.net
                Cc: Hector Santos; IETF-MAILSIG
                Subject: Re: DKIM Verification Algorithm
                
                
I think I missed the beginning of this thread somehow. I think this matrix came from Hector; I rather like it because it frames the discussion well:
                
I will draw the outcome table in text mode. View it in
                fixed pitch mode.
Table 1.0 - DKIM Verification States illustrates all possible outcomes for signature verifcation against SSP.
                                
+------------------------------------------------------+ | Sender Signing Policy Result |
                                
                
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER
                | NONE  |
| verify | OPT | OPT/3PS | REQ/3PS | REQ |
                |       |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject
                | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject
                | warn  |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject
                | warn  |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn <.-+> warn | reject
                | warn  |
|-----------+--------+---------+-------+-+--------+--------+-------|
| FAIL 3PS | reject | warn | warn <|-+> reject| reject
                | warn  |
+--------------------------------------+---------------------------+
Maybe I'm focusing on an optimization here, but I'm still trying to see if we can avoid checking SSP when there is a valid originator signature present. The primary case here that requires it is NEVER. In that case, the originating domain must have published some key records, but is asserting that it doesn't send any mail. This seems like a conflict, which could be resolved in either direction. I tend to think that having a valid signature is a stronger assertion than the SSP, so why not fold NEVER into EXCLUSIVE?
                
Also, I think that a valid OA signature shouldn't result in a warning if there is no SSP published, which makes NONE the same as NEUTRAL, again for the reason that the signature is a stronger statement than the policy. It also makes publication of policy optional.
                
                -Jim
                
                
                
        
        "Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
         annotations on 08/04/05 08:17:15
        
--------------------------------------------------------------
----------------
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
        
==============================================================
================
        


"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
annotations on 08/04/05 08:46:26
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary 
information, and may be used only by the person or entity to which it is 
addressed.  If the reader of this e-mail is not the intended recipient or his 
or her authorized agent, the reader is hereby notified that any dissemination, 
distribution or copying of this e-mail is prohibited. If you have received this 
e-mail in error, please notify the sender by replying to this message and 
delete this e-mail immediately.
==============================================================================

<Prev in Thread] Current Thread [Next in Thread>