ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-08-02 11:35:55

----- Original Message -----
From: "John L" <johnl(_at_)iecc(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>


John wants to know how a 2nd signature could invalid an already valid
message.  This is really based on a "Good Citizen" model where
everything is done correctly.

Actually, it's based on the model in draft-ietf-dkim-base-04.txt.

As always, concrete scenarios would be a great help to understand the
problems you believe exist.  In particular, a concrete example of a second
signature invalidating a message without breaking the first signature
would be extremely useful since it would point out a major flaw in
dkim-base that nobody else is aware of.

First, this is why I suggested the requirement: SSP Must Follow DKIM-BASE,
because there is going to be alot of revisiting here based on what
requirements are set or excluded.

Second, I don't think you can find an example because you provided a perfect
scenario where everything was done right with a mindset where we have a very
loose interpretation of multiple signatures.

Third, Not so John.  Many were aware of the multiple signature issues. You
probably missed this discussions.

Eric, Jim, myself and others, were very aware of the problems because it was
discussed in quite detail that help shape the loose semantics of Multiple
Signatures as altered in base-01.  The semantics were changed because of the
vague issues of multiple signatures.

In base-04 it says:

   4.  Semantics of Multiple Signatures

   ...

   Signers should be cognizant that signing DKIM-Signature headers may
   result in signature failures with intermediaries that do not
   recognize that DKIM-Signatures are trace headers and unwittingly
   reorder them.

It also says:

   ..... As with messages with a single signature,
   verifiers are at liberty to use the presence of valid signatures as
   an input to local policy; likewise, the interpretation of multiple
   valid signatures in combination is a local policy decision of the
   verifier.

Do we have a consistent set of local policies for everyone?

I also had a problem with this statement:

   Signers SHOULD NOT remove any DKIM-Signature header fields from
   messages they are signing, even if they know that the signatures
   cannot be verified.

Because this prohibits (limits) the list server from having fun in the DKIM
sand box. It didn't help my list server change designs. It makes things
harder and to ignore it does not help address survibility issues.

But it is also flawed because it presents a high potential for failure for
the verifier to question.  This we can demonstrate with Domainkeys in the
wild. Nearly all of this coming from what seem to be mailing list, fail.

You really need to read that interesting thread where multi-sigs discussed
in quite detailed with pseudo-code illustrations.

Also consider this:

6.1  Extract Signatures from the Message

   A verifier SHOULD NOT treat a message that has one or more bad
   signatures and no good signatures differently from a message with no
   signature at all; such treatment is a matter of local policy and is
   beyond the scope of this document.

   When a signature successfully verifies, a verifier will either stop
   processing or attempt to verify any other signatures, at the
   discretion of the implementation.

Again, Local policies questions.  No clear behavior on how to handle
multiple signatures and its possble failures.

John, the whole point here is that you presented the result where the
message was 'perfect' but it was based on ignoring if the 2nd signer itself
violated any SSP policy.  Was it suppose to resign?

Excluding the possibility of exclusivity to help define policies that local
system may follow in order to help and/or increase the survibility of the
DKIM signed message is not a very good idea.

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





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