From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
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
And that is another major problem in itself. It is easy to become paralysed by
past experience. Some of what was possible in 1985 became impossible in 1995
and some of what was impossible in 1995 is possible today.
The objective here is dilectic. For DKIM to succeed the amount of arbitrary
message modification has to decline sharply. Fortunately this is already
happening to some degree.
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.
The selector in the signature header tells you where to find the key
The selector in the policy record, if present, tells you that you should expect
at least one signature header which has a selector with the specified prefix.
So if you have only one DKIM signature header of the form
DKIM-SIGNATURE: s=key1.sha3keys d=example.com ....
It tells you to look for a key record of the form:
key1.sha3keys._domainkey.example.com TXT "h=sha3 ...
If the signature verifies then you are done!
If on the other hand you do not support SHA3 which is not suprising you go to
the policy record to decide if the message is consistent or inconsistent with
policy.
If the policy states:
_outbound._smtp.example.com TXT "DKIM"
The message is consistent since the message has a DKIM signature header. The
header did not fail verification so we do not need to ignore it completely (and
yes I noted the wording in base very carefully at the time), instead we note
that there is an unverifiable signature header and the message is compliant
with policy
RESULT: Message goes to content filtering as if the signer had no DKIM
signature or policy statement.
If on the other hand the policy states:
_outbound._smtp.example.com TXT "DKIM=sha2keys"
The message is not compliant with the specified policy. key1.sha3keys does not
match *.sha2keys.
So we have a policy inconsistency here.
The consequence of the policy violation would depend on various factors. If the
receiver was some sort of mailing list or remailer then the most appropriate
course of action might well be to simply reject the message. If the receiver
was a personal inbox and domain was on a list of commonly targetted domains
issued by the APWG then the most appropriate course of action might be REJECT.
Otherwise we would process the message using content filtering but with the
constraint that if the message is legitimate it must have been forwarded
through a legitimate forwarding relationship.
If on the other hand you had started with two signatures:
DKIM-SIGNATURE: s=key5.sha2keys d=example.com ....
DKIM-SIGNATURE: s=key1.sha3keys d=example.com ....
If either signature could be verified the message would be accepted without
ever retrieving the policy record.
If both signatures fail verification we have a policy inconsistency and deal
with it as before.
There are two outcomes possible with DKIM Base: VERIFIED and UNKNOWN
There are three outcomes possible with DKIM Base+policy: VERIFIED, UNKNOWN and
INCONSISTENT
The whole point of policy is to establish the possibility of the third outcome.
The point of checking policy is that a message that receives the outcome
INCONSISTENT is treated less favorably that UNKNOWN. Less favorably may mean
outright rejection or merely different content filtering parameters.
The only constraint that BASE gives us is that messages with broken signatures
should map to the same states in the same circumstances as messages with no
signatures at all.
Notes:
* No additional DNS lookups took place.
* There is no optimization value in fetching the policy before checking the
signature in any case
* The policy record does not specify the hash algorithm.
* The key record specifies the hash algorithm.
* This proposal is much simpler than SSP.
* This proposal is more powerful than SSP.
* This proposal makes it much easier to understand policies than for SSP
* This proposal is considerably more extensible.
* If you use fully qualified domains in the selector specification
(sha2keys._domainkey.example.com) you could even express policy of the form
'all mail for domain X is signed by domain Y'.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html