Amir Herzberg wrote:
Still new to DKIM (from draft-allman-dkim-base-00) so please bear with
me if I'm raising old issues; didn't identify them in the archives.
Looking at section 6.3 `Get the Public Key`... two questions/comments:
1. It says Verifier MUST retrieve public key... Always? Why not include
some key identifier and allow the verifier to use a cached key (based on
the identifier)? Of course, if key retrieval is using DNS, then the DNS
caching mechanism will also make this a local operation. But I think
there are several advantage to allowing a key identifier and a key cache
at the verifier. One motivation follows.
The intent is to use DNS caching, yes. Note that a DKIM implementation
is certainly more than welcome to contain a caching resolver for
efficiency.
2. There is an implied assumption here that we always use public key
signatures. Why rule out the use of shared key authentication, for
improved performance, e.g. in the (common) scenario of authentication
between the border MTA of two large ISPs (with long term relationship)?
Here, it may be desirable to avoid the key retrieval (via DNS), as the
key should be pre-shared anyway, possibly first sending message with
signature until the pre-shared key is established.
Clearly you couldn't pre-share the key in DNS :) In the case
where you have a bilateral agreement, why not just use TLS or,
say, SMTPAUTH? DKIM is really trying to fill the gap of communicating
between domains that don't necessarily have a relationship with
each other; there are multiple ways to tackle that problem when
they do have a relationship, and I'm somewhat doubtful that DKIM
would bring much added value in those situations.
Mike