ietf-mailsig
[Top] [All Lists]

Re: DKIM: key identification and shared keys

2005-08-03 02:08:21

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

<Prev in Thread] Current Thread [Next in Thread>