On Sat, 2006-04-01 at 21:56 -0800, Dave Crocker wrote:
Barry Leiba wrote:
And I'd like to get us to close on two other discrete parts:
1. Whether we want to have a mechanism to let the signature survive
the reordering of multiple sig headers or not.
...
2. Whether we want to be able to detect the removal of a signature
header (as perhaps in the case of a "stronger" one and leaving a
My question for each is why?
To do either of these requires additional mechanism.
Yes for 2. Perhaps a simple mechanism added optionally.
So the question is what benefit will accrue... and why that benefit
is essential to a task of the type DKIM is intended to perform?
Transitioning algorithms in signed email may take long periods of time.
When there are exploits possible with a prior algorithm being phased-
out, until it is possible to ensure acceptance with just the newer
convention, including both conventions will be required. This period
could span a significant amount of time, and depend upon the motivation
of all verifiers.
Not have a mechanism to detect when the stronger signature is missing
means even when the verifier does support a newer convention, the
exploit remains possible, even for those verifiers that care about the
problem. Selectively sending or verifying adds a greater amount of
overhead.
A simplest scheme would be to mark keys and signatures either primary or
secondary and delete prior signatures. For signatures to be retained
with common domains at the MSA, Mediator, or MDA, these roles could be
combined with the primary/secondary indication. This differentiation of
sources for signatures should safely allow these roles to establish a
set of signatures that can be retained without domain conflicts.
The greatest difficulty would be establishing an MSA instance that signs
in the role of the Mediator, for use with list-server applications, as
example. Everything else would be statically defined. Rules for
handling signatures could default existing headers to be MSA-Primary
without causing a problem. When the role is added to the signature/key,
it would be the same for all messages and require just a small amount of
fixed text.
There is another benefit signature roles provide. This benefit is found
when a local trust database are being maintained. These signature roles
could minimize user interaction and improve security. This interaction
might occur when a conflict otherwise appears to exist. These trust
databases would be used for message annotation. A message with a
signature with a non-matching role could be silently ignored, as it
would not receive the annotation. This annotation might be which folder
the message is placed into, for example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html