Subject: RE: [ietf-dkim] New issue: Requirement #10 - Invoking SSP - Suggestion to Remove this.

From: Arvel Hathcock <[email-masked]>
Date: Tue, 26 Sep 2006 13:26:00 -0500

> 10.  The Protocol MUST NOT be required to be invoked if a
>      valid first party signature is found. 

Hector, doesn’t it say exactly what you want it to say?  It says that the protocol must not require invocation when valid first party signatures are found.  It doesn't say "THOU SHALT NOT INVOKE THE PROTOCOL".  I see nothing that needs to be changed.  

-- 
Arvel 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Sep 2006 11:51:04 -0700

On Sep 26, 2006, at 11:26 AM, Arvel Hathcock wrote:

>> 10.  The Protocol MUST NOT be required to be invoked if a valid  
>> first party signature is found.
>
> Hector, doesn’t it say exactly what you want it to say?  It says  
> that the protocol must not require invocation when valid first  
> party signatures are found.  It doesn't say "THOU SHALT NOT INVOKE  
> THE PROTOCOL".  I see nothing that needs to be changed.

There might be policies associated with the local-part of the  
referencing email-address domain.  Depending upon how this policy is  
being used, it may be required by some protocol to obtain this policy  
record.  Assume this would only happen when the email-address domain  
is considered trustworthy, and that there might be conditional  
constraints that might be applied, such as those that may pertain to  
the local-part.

Not everyone within any domain should be assumed trustworthy.  When  
attempting to define a protocol for indicating an additional level of  
trust, there might be a need to further constrain the assertion.   
That additional constraint would be required even when the signing  
domain matches the email-address domain.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 26 Sep 2006 15:13:23 -0400

Hmmm, the subject title is misleading. It is better titled:

  New issue: Requirement #10 - Short circuiting SSP
            - Suggestion to Remove this.

----- Original Message -----
From: "Arvel Hathcock" <[email-masked]>
To: <[email-masked]>

> that the protocol must not require invocation when valid
> first party signatures are found.  It doesn't say "THOU SHALT
> NOT INVOKE THE PROTOCOL".  I see nothing that needs to
> be changed.

At best this is an optimization implementation consideration and typically,
we try avoided it in protocol designs, especially this one.

Because from one perspective, you are correct only when there is a
PRESUMPTION that the policy is correct and you are trying to short circuit
the lookup if the 1st party signature is valid.

You are presuming the policy is correct, but you made no statement whether
you care whether it is or not, or whether it exist when the 1st party
signature is valid.

First, if that is the case, the document should atleast touch based with the
idea that a valid 1st party signature does not require SSP nor does it care
if 1/2 of the security is broken!

Second, the consideration is more appropriate to be stated as:

  If there is a 1st party signature detected, then
  the implementator MAY perform a DKIM-BASE validation first
  and MAYBE perform a SSP if and only if the 1st party
  signature was invalid.

The problem?

Implementators might create a performance and scalability problem depending
on the failure rate.  The higher the rate, you reach a break-even point
where performing SSP first might provide you the better results without the
DKIM hash verification overhead.

This req #10 is misplaced and if anything it should be part of section 5.1
Discovery Requirements.  Not part of section 5.2.  But DNS optimization is
already implied in section 5.1.  So this req #10 is not useless.

Third, if you look at the DSAP verification Figure 2.0 (below) there are
atleast high potential states or detectable transactions which does not
require any high overhead DKIM verification.

So from engineering standpoint, the optimization favors the SSP lookup at
all times in order to weed out the most highly probable bad-DKIM mail
states.  When this is widely adopted, there is no doubt in my mind, it is a
much better design than what requirement #10 will promote.   So rather than
argue for specific implementation methods, requirement #10 should be removed
simply because based on its technical merits it is flawed.  It is in trouble
in a high-volume of failures.

I will work and play by the decision made by the WG but I can not be
convinced it is the right technical decision.  This requirement will not be
followed in my design simply because it isn't the right one, plus, it
doesn't belong in a requirements document.

     Figure 2: DKIM Signature Authorization Protocol Outline

     +-----------+
     |  PAYLOAD  |
     +-----------+
          |
          v
   +----------------+
   |                |                            +------------+
   | DKIM           |--------------------------->| CONTINUE   |
   | Signature      | UNSIGNED: OPTIONAL         +------------+
   | Authorization  |
   | Protocol       |
   |                |                            +------------+
   |                |--------------------------->|            |
   |                | SIGNED: EXPIRED (1)        |            |
   |                |--------------------------->|            |
   |                | NO MAIL EXPECTED (4)       | FAILURE/   |
   |                |--------------------------->| CLASSIFY   |
   |                | UNSIGNED: REQUIRED (5)     |            |
   |                |--------------------------->|            |
   |                | SIGNED: NOT EXPECTED (6)   |            |
   |                |--------------------------->|            |
   |                | 3P SIGNED: NOT ALLOWED (7) |            |
   +----------------+                            +------------+
          |
          |
       SIGNED
       MESSAGE
          |
          v                                      +------------+
     +--------------+                            | CONTINUE/  |
     |              |--------------------------->| CLASSIFY   |
     |              |    INVALID SIGNATURE       +------------+
     | DKIM         |
     | SIGNATURE    |
     | VERIFICATION |                            +------------+
     | (8)          |--------------------------->| PASS       |
     |              |    VALID SIGNATURE         +------------+
     +--------------+

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Sep 2006 12:48:01 -0700

>Hector, doesn’t it say exactly what you want it to say?  It says that the protocol must not require invocation when valid first party signatures are found.  It doesn't say "THOU SHALT NOT INVOKE THE…
Exactly.

       Mike

---

From: [email-masked] (Wietse Venema)
Date: Tue, 26 Sep 2006 16:08:30 -0400 (EDT)

Michael Thomas:
> >Hector, doesn_t it say exactly what you want it to say?  It says

I agree.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Sep 2006 13:40:31 -0700

>>> THE PROTOCOL".  I see nothing that needs to be changed.

Are these policies to be used in only one protocol, or might there be  
multiple protocols that make use of these policy records?

-Doug

---

From: <[email-masked]>
Date: Tue, 26 Sep 2006 18:07:07 -0400

Doug,
The protocol we are discussing is DKIM, although another protocol might
find SSP useful it's out of scope for this discussion.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Tuesday, September 26, 2006 4:41 PM
To: [email-masked]
Subject: Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP
-Suggestion to Remove this.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Sep 2006 15:24:38 -0700

On Sep 26, 2006, at 3:07 PM, <[email-masked]>  
<[email-masked]> wrote:

> The protocol we are discussing is DKIM, although another protocol  
> might find SSP useful it's out of scope for this discussion.

Agreed.  The policy being discussed relates to the handling of  
messages associated with DKIM.  There could be protocols defining the  
handling at the MUA, versus protocols that define handling at the  
MTA.  Two message/policy protocols based upon DKIM messages at  
different stages of delivery.   These are significantly different  
environments with different limitations.  At the MTA, it seems  
reasonable to limit when a policy record is required.  At the MUA,  
different requirements apply when a message is being annotated.   
Without annotation, DKIM provides virtually no protection.

-Doug