[ietf-dkim] multiple query mechanisms, was Today's jabber

[Eric Allman]

[I chose Paul's message to reply to more or less at random --- it's 
really a response to the thread.]

I'm leaning toward SHOULD, in part because of Paul's quoting of 2119:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
> there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood
> and
>     carefully weighed before choosing a different course.
> . . .
>     Imperatives of the type defined in this memo must be used with
> care
>     and sparingly.  In particular, they MUST only be used where it
> is
>     actually required for interoperation or to limit behavior which
> has
>     potential for causing harm (e.g., limiting retransmisssions)
> For
>     example, they must not be used to try to impose a particular
> method
>     on implementors where the method is not required for
>     interoperability.
>
> ...
>
> Can you give an example of how you think the two might differ in
> light of:
>     If there are
>     multiple query mechanisms listed, the choice of query mechanism
>     MUST NOT change the interpretation of the signature.

Speaking pragmatically, there are a couple of reasons I can think of 
where the signer might prefer that verifier query in a particular 
order:

* One mechanism might scale better than another, for example, the 
signer might have a big honking http-based server (postulating for a 
moment a future http-based key query algorithm) and a measly little 
DNS server.

* A signer might be in the process of transitioning, and would like 
to measure how many verifiers really need the old mechanism.

* There might be some "information skew" between different sources 
--- for example, one is a cache which lags another source slightly.

* One might be a copy that the signer would prefer be used, but the 
signer is willing to have verifiers use the direct source if the copy 
is down.  In some sense this is the same argument as MX records with 
non-equal weights.

All that said, you can't force the verifier to do anything, hence 
MUST is inappropriate.  SHOULD feels right to me.

(And yes, I realize that the "skew" argument violates the principal 
that the sources should all be equivalent, but pragmatically it's not 
likely that the signer is going to implement a transaction-based 
store across multiple different technologies.  And besides, there's 
skew in DNS, so we can't escape it.)

eric