----- Original Message -----
From: "Eric Allman" <eric(_at_)neophilic(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Current model:
TCO(DKIM1) = TCO(HASH-BODY)+ TCO(HASH-HDR) + TCO(SSP)
The order of the processing above is important.
The SSP cost is not always paid; in fact, we hope that the long term
stable state is that it is seldom incurred. But that, of course,
depends on what happens when we get to the SSP details.
Right, and maybe I have a bias. I'm trying really hard removing all
concepts of a SSP from my mind. I see SSP as a fundamental requirement. I'm
have a terrible time envisioning a DKIM network working very effectively
without a Sender Signing Policy (SSP) concept.
The more optimal model when considering order is:
TCO(DKIM2) = TCO(SSP) + TCO(HASH-HDR) + TCO(HASH-BODY)
From the signer side, you have to hash the body before the header for
the current proposal to work, since the body hash has to be included
in the header hash. From the verifier side the two hashes do (or
can) happen in the order you describe. But I don't understand why
you say that SSP comes first in this model. As I understand it, this
proposal says nothing whatsoever about SSP.
That is correct, but it pertains to the overall modeling. The assertion is
still "generally" true even if we remove SSP:
TCO(DKIM1) := TCO(HASH-BODY)+ TCO(HASH-HDR)
TCO(DKIM2) := TCO(HASH-HDR) + TCO(HASH-BODY)
TCO(DKIM2) <= TCO(DKIM1)
Of course, this assertion is even greater when the body length increases.
My points is that from a VERIFICATION standpoint:
- Analzing the HEADER comes first
- Analying the BODY comes second
Can a HEADER failure pre-empt (short circut) a BODY analysis? I would hope
so.
In regards to SSP, to me, it is a moot point what the HEADER or BODY says if
there is a conflict in the signature authorization. So I would add SSP
first in the steps:
- Analzing the SSP is first
- Analzing the HEADER comes second
- Analying the BODY comes thirs
In my mind, this is both Technically and Economically more feasiable
offering the greatest value.
Why?
Well, to me, here we are trying to introduce some new "entity" into the mail
stream and we are trying to do it transparently. If its done in a relaxed,
unrestricted and optionally mode, then we end up repeating SMTP history in
regard to HELO client machine domains and MAIL FROM: return path where we
ended up with absolutely no trust in their reliability or "trustfulness,"
inevitably returning us back to a mode where there is no added-value or
sense in processing the information.
In SMTP, the HEADER comes first, the BODY is second nature. The HEADER must
be correct first and it must be consistent with the signature. Per
specification, currently, we can avoid the header with a empty h= tag. Is
this allowed?
- SSP processing offers short circuiting of remaining
processing overhead
How? (I suppose that originators that have an SSP saying "we never
sign anything" could short circuit it, but that's pretty borderline).
Why? I personally think it will be more prevalent. I already see messages
with DKIM/DK signatures from domains that have NO KEY policy. MSN.COM is
one that comes to mind. Without SSP, this DKIM processing is more closely.
Also, the cost of SSP is likely to be fairly expensive since it
involves network delays; hashing responds nicely to CPU improvements.
Ok, I came to joining and getting more involved in the IETF groups nearly
2-3 years go because of my lack of expertise in the DNS and to see how
expensive it will be with the direction of new DNS based proposals.
Today, after writing my own DNS clients and studying DNS server source
codes, etc, although I think there are issues with DNS lookup failures, I
believe it can not be a source of throwing out a very effective means of
controlling abuse and exploitation of domains. DNS lookups can be caches,
so I don't see that is a big thing today.
So to me, the high sampling cost (not looking at just 1 message)
TCO(SSP) <= TSO(HASHING)
Again, the HASHING can be very high depending on ALG and length.
But I agree this is more a implementation design. My concern is how it can
help mode the base system. For example, a SSP can offer more than just
exposing policy. It can define how a signature is expected to be stamped.
- HASH-HDR processing offers short circuiting of remaining
processing overhead
Yes, on the verification side.
and so on.
There's also the cost of RSA, but I don't think that applies here
since it's a constant in both equations (add "+ c" at the end of each
one...).
Agreed.
I do believe that the total cost to both verifiers and signers that
have to send fixed bodies will go down in the new proposal, but it's
hard to tell by how much.
Agreed.
Mostly I'm just not understanding your point about SSP.
Again, since I have it in my mind that SSP is a fundamental part (and I have
hard time seeing us not implementing it - you guys will come to your senses
<g>) I find it difficult to define a BASE system that completely ignores
SSP.
We have issues regarding SHA1 or SHA256 or a FUTURE alg, - SSP solves this.
We have issues with cost of hash processing - SSP can help resolve this
cost.
We have issues regarding LIST servers - SSP can help tremendously in
defining how LIST servers should behave.
There is so much value in SSP, I can't see how effective a DKIM system can
be in a model that is based on an expected flood of DKIM messages where the
only way to effectively test it is to perform the processing. The best
protection is obtained by stopping those who are fraudulently using other
people's domains. That can only be done with something like SSP. The KEY
record will give you the same result but I don't think as strong as a SSP
can offer.
My opinion of course.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html