Subject: RE: [ietf-dkim] Attempted summary, SSP again

From: <[email-masked]>
Date: Fri, 27 Jan 2006 11:08:00 -0500

" If it has a valid first party signature, it passes. If it doesn't,
it doesn't." If the value of the valid signature states that 3rd party
signers are not admissible it does impugn the validated first party
signature. So should the first party remove 3rd party signatures? Or
should the text read

>>      "!  All mail from the entity is signed; Third-Party
>>          signatures SHOULD NOT be accepted in lieu of an entity
signature

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 Michael Thomas
Sent: Friday, January 27, 2006 10:52 AM
To: Hector Santos
Cc: [email-masked]
Subject: Re: [ietf-dkim] Attempted summary, SSP again

Hector Santos wrote:

> ----- Original Message -----
> From: "Michael Thomas" <[email-masked]>
> 
>>>For the EXCLUSIVE policy?  Following SSP, it would be a
>>>REJECT because the policy says no 3PS should exist.
>>
>>That's not what it says. It says:
>>
>>      "!  All mail from the entity is signed; Third-Party
>>          signatures SHOULD NOT be accepted"
>>
>>In the context, it means that it requires a first party signature.
>>It should probably be more explicit on this point.
> 
> 
> In the context of the Levine's question,
> 
>    Levine:
>    "if a message has both a signature from the From: domain
>     and one from someone else, does that pass?  Why or why not?"
> 
> Following your SSP draft description as posted above, this would be an
> unaccepted condition.
> 
> What is the difference?

The second clause is only trying to make explicit that a third
party signatures is not an acceptible substitute for a first
party signature from that domain. Which it isn't. You're making
a leap that it should also cast a shadow on the first party
signature. The text definitely does not say that, and it was
not the intent since we were purposefully dancing around the
multiple signature question.

If it has a valid first party signature, it passes. If it doesn't,
it doesn't.

		Mike
_______________________________________________
ietf-dkim mailing list
http://dkim.org

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jan 2006 08:19:19 -0800

[email-masked] wrote:
> signature. 

   No, it should just treat it as if it didn't exist for the purposes
   of the ssp check.

> So should the first party remove 3rd party signatures? 

   Assumedly, most of these third party signatures will be added after
   the first party signatures so in the normal case it wouldn't have
   the opportunity.

> Or
>>>         signatures SHOULD NOT be accepted in lieu of an entity signature

   Yes, that's what it's supposed to mean.

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 11:29:18 -0500

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: <[email-masked]>

>    the first party signatures so in the normal case it wouldn't have

You are making in flawed assumption about how things are going to
behaved. You can't design a protocol like this.

The protocol verification process has to work on the basis of consistent
logic and expectations of the system regardless of how the message was
created or not.

signature
>    Yes, that's what it's supposed to mean.

So in other words, for the EXCLUSIVE (o=!) policy.

    DO NOT ACCEPT IF AN OA SIGNATURE IS MISSING.
    DO NOT ACCEPT IF A 3RD PARTY SIGNATURE IS PRESENT.

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 27 Jan 2006 18:03:00 +0100

>     DO NOT ACCEPT IF A 3RD PARTY SIGNATURE IS PRESENT.

Only the first DO NOT.  The second DO NOT is unnecessary and
potentially harmful.  What if the author is forced to send
via a route where a 3rd party routinely adds its signature
without caring about SSP ?  

What if the receiver forwards his mail to another MRN, and
his clueless forwarder always adds a 3rd party signature ?

The important point is the first DO NOT. the second would at
best save you (as the checking receiver) a few lines of code.

                               Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 12:45:05 -0500

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>

> potentially harmful.

Ok, lets discuss that. But keep in mind that is not specification. The
specification clearly says "No 3rd party."  (So John, it is a REJECT.)

We can discuss a proposal to change draft specifications, I am all for
it. Steve wants us to wait, but ....

> What if the author is forced to send via a route where a
> 3rd party routinely adds its signature without caring
> about SSP ?

There are two parts here:

    - Exclusive domain using his domain in public
    - Non-Compliant DKIM/SSP resigner

That non-compliant DKIM/SSP signer is going to cause trouble for any
DKIM domain using that server.

Don't you think the exclusive domain is irresponsible for using it?  He
shouldn't be using an exclusive policy because, according to the SSP
spec, the DKIM verification can fail it.  It says no 3rd party. The
final machine will fail it.

If he wants to allow this or he is forced, then he needs to use a
different policy that allows 3rd party signing.

> his clueless forwarder always adds a 3rd party signature ?

Again, consistency.  If anyone breaks it, it isn't going to work.  We
would be talking about non-compliant software - a buggy DKIM/SSP
software.

> best save you (as the checking receiver) a few lines of code.

if DKIM/SSP can not offer an exclusive, no 3rd party signing protocol,
then we are really just wasting our time :-)

That's like saying SPF has no -ALL policy :-)

It if  didn't, I don't then many would of supported it.  Not that it is
a MUST, but not to offer it?  I would not have been a very good idea.

Same with DKIM.  You need an exclusive policy and software must support
it.  If we can't have that confidence, and what's the use? :-)

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 27 Jan 2006 20:21:05 +0100

Hector Santos wrote:
 
> keep in mind that is not specification

Okay, but at this time of the WG work I still think that the
concept of "re-signing" is utter dubios.  Without "re-signing"
it's simple to pick the "right" signature for checking, and 
your algorithm "exclusive and less or more than one signature
=> reject, can't be okay" would work without going into the
fine print for "exclusive".
                                Bye, Frank