ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-08-02 06:23:09

Hector,

Yet another claim of utility with no demonstration!

I do agree that we have to cater for an imperfect world,
but you have yet to demonstrate a case where that makes
it bad to add signatures to a signed message (from a
bank or whatever).

Why don't you(*) just show me the benefit? If its because
you think this should be useful but aren't sure exactly
how, then that's fine, just say so and the WG can take
that into account when evaluating which requirements to
adopt.

(*) By "you" I don't mean just you personally, but all
the folks on the list that are arguing for this.

Cheers,
S.

Hector Santos wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "John Levine" <johnl(_at_)iecc(_dot_)com>


John Levine wrote:
If you disagree, you really have to provide a concrete scenario where
an added signature turns a valid message into an invalid one, keeping
in mind that the existing message headers and the messge body did not
change at all, since the original signature is still good.
Sorry to keep hammering on about this, but I'd really like to see this
answered. So far it hasn't been and I believe the WG wouldn't be wise
to adopt requirements where we've only got claims of utility but no
demonstrations of utility.

The demonstation of utility is a digital mail signature model based on some
c14n and hashing of mail - a concept that deals directly with mail integrity
issues.

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.

He prepared all process conditions so that there is no integrity issues. So
no harm is done.  Everything works fine.

But what happens when all or some conditions are not set?  There is a change
in the body? The original signature was stripped?  Or just about anything we
don't know, but the OA did not expect any of this to happen?

Thats the challenge here.

PS: Just wondering. Is this a case where people are thinking that
just because a signature is a positive thing, that there must exist
a meaningful opposite - an anti-signature or something?

HA! <g>

Why not try the reverse the question? Show when it doesn't cause in harm?
John told us. When the universe is perfect. :-)

Well, this
isn't particle physics (luckily!) and afaik there is no such
construct as a negative signature. (Yes a signature can be over a
negative statement, but DKIM-base signatures sign mail, not policy
assertions.) So a policy/practice statement that even implies that
some signatures are anti-signatures makes no sense. (At least in
my Universe:-)

The "grass" is indeed greener over the pond. <g>

The perfect DKIM universe is wonderful. I think  this is why people are
excited about. The potential is high for success among all parties, the
small and the large, the ISP, ESP and the users, etc.

But in my view, the perfect DKIM universe is not reality. There are going to
be attempt to break john's perfect message scenario.

If we have history to work with here, there is a strong indication that the
DKIM universe will not always be perfect.

The question is how do you handle imperfection. Is it worth handling it?

So as you know, for me, DSAP was done as a concern about the security
concerns of the core DKIM-BASE protocol when the universe is not so perfect:

  "The main objective of DSAP is to establish a
  protocol consistency between all client types and to use the
  deviation from the consistency as part of a failure detection system."

I think that trying to define requirements does requires an understanding of
what the signature security concerns for DKIM-BASE protocol.  It begins
there, in my view.  What are the possible signature security problems?

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




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