[ietf-dkim] Deployment Scenario 7: Cryptographic
Upgrade andDowngrade Attacks
hsantos at santronics.com
Wed Feb 28 06:19:34 PST 2007
Hallam-Baker, Phillip wrote:
> The discussion here is about a REQUIREMENT. How the requirement is
> achieved is not the issue at this point.
> Of course since everyone seems to skip straight to the implementation,
That is what happens in a mixed discipline environment. :-) Plus there
is 100s if not 1000s of man-years experience here - foreseeing
implementing is not to be unexpected with all the knowledge here. I for
one see implementation issues with some of the proposal provisions so
you expect it to be mentioned.
> The policy record does not directly reference the signing algorithm, all
> that information remains in the key record. All that you get in the
> policy record is a statement 'there is always a key record that has a
> selector that looks like this' or 'there is always one like this and one
> like that'.
I don't understand why. The ultimate selector is the one in the
> Lets hold off on the implementation though as Steve will no doubt remind
> us is the basic idea at this point. This means that we only discuss
> whether it is a valid requirement. The cost of implementation is not the
> issue at this point.
Of course, implementation doesn't mean "coding." It is about the
process model. You must have some insight into this to have an
understanding of the problem and possible solution.
The ideal situation is:
"Having all the information one needs to make a decision."
The total process DATA pool is:
- DKIM Message
- KEY information
- SSP information
VALIDATION = VERIFY(MESSAGE, KEY, SSP)
or as some will want that to be:
VALIDATION = VERIFY(MESSAGE, KEY[, SSP])
with an optional SSP.
So the question is, can an OPTIONAL SSP or a DELAYED SSP implementation
be used to address all the concerns?
From my standpoint you have these design points:
- Is mail expected is this a valid condition?
- The mail is signed, is this a valid condition?
- The mail is unsigned, is this a valid condition?
For that all you need is
a) SSP record, or
b) for no mail or no signatures, all you need is no KEY record.
So as you can see, the decisions dictates how the process modeling will
Beyond that, we are trying to KLUDGE a solution into "Signature Failure
Fixing" and to me, that will be exploited.
Maybe it will help if we define what kind of failures are worth "fixing."
More information about the ietf-dkim