ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

2007-02-28 07:23:45
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 DKIM-Signature heeader.

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

or

   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 be done.

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."

--
HLS


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