Michael Thomas wrote:
Amir Herzberg wrote:
...
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.
That's what I thought; may I suggest making these assumptions explicit?
(I can suggest text if needed)
I think that using the DNS cache here is a very reasonable strategy, and
in particular may simplify DKIM implementations, which is good. However,
I think the spec should also allow for other key-caching strategies,
e.g. if the key retrieval will not use DNS.
In particular, it may make sense, for security-concerned receivers, to
require stronger authentication of the public key, not just rely on the
(insecure, currently) DNS. Such key management mechanism may use DNS as
key distribution channel, but not rely on it for key authentication (but
e.g. use a certificate for that). Relying on key expiration using DNS
TTL will introduce a vulnerability here. The addition to the spec is
minor, it will just say recipients MUST get an updated version of the
key; recipients SHOULD be able to retrieve an updated version via DNS,
and recipients MAY get a key from a local cached copy if still valid,
and MAY use other mechanism to retrieve updated key. [this is not a
suggested wordings yet...]
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.
...
In the case where you have a bilateral agreement, why not just use TLS or,
say, SMTPAUTH?
Right. However, these are connection mechanisms. While I agree that a
common use is to authenticate the cross-border MTA connection, I believe
we also want to allow DKIM use for authenticating across an MTA,
possibly even MUA-MUA. Consider even use of multiple DKIM fields, one
with a public key signature, other(s) with shared key authentication to
reduce load from recipients.
And, there may be cases where sender _may_ have a shared key, but may
not be sure that the recipient (already/still) has it; using an
additional shared key auth in DKIM would work, using IP-Sec/TLS/SMTPAUTH
may result in rejection.
Also, I think a DKIM authenticator could even be valueable when signed
by a symmetric key known _only_ to the sending domain, to authenticate
bounces, similarly to SES/BATV. Of course, we get similar benefit by
using shared-key with the recipient, or using a signature (except for,
again, performance considerations, including DoS).
In any case, why should the spec exclude a shared-key solution?
Even a Kerberous-like, key distribution center solution?
--
Best regards,
Amir Herzberg
Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame