On Sat, 2005-08-06 at 22:05 +0000, John Levine wrote:
DCC users are all familiar with this problem, since it means that we
have to manually whitelist all of the mailing lists we subscribe to to
keep them from being caught by DCC. Having lived with it for a couple
of years, I strongly think that it's not something that we should try
to mix into a signature authentication scheme. If it's important for
DKIM, why wasn't it equally important for S/MIME and PGP?
This concern seems to center on the general goals of DKIM. Rather than
declaring user-keys, as with S/MIME and OpenPGP, DKIM allows the entire
domain to share the same public key. When done in this fashion, the
impact created by per-domain keys, rather per-user keys, would represent
an incremental increase of traffic carried by DNS. Domains also provide
non-uniform distribution of use, which also helps to minimize the
impact. Here DKIM establishes an accountable domain that should respond
to reports of abuse, in order to retain a good reputation and to protect
their recipients.
User-keys in DNS could have a significant impact on DNS traffic. When
compared to the overall traffic carried by the the messages, this would
represent just a percentage of increase. But when considering the
impact on DNS cache, the effects could be far greater. Perhaps one
solution for protecting the DNS cache would be to severely limit any TXT
or KEY record's TTL. However, short TTLs for user-keys AND domain-keys
would impact the overall performance of email, as every operation would
likely suffer a DNS lookup, with perhaps an increase in the already high
DNS response loss rate. With long time-outs and damage to DNS cache,
the affect that user-keys may have on DNS could be damaging other
applications as well.
With per-user keys, such as with S/MIME, key revocation is solution to
address abusive behavior, which includes abusive replay. When not using
IP address based reputation, but instead depending upon a verified
signature, the normal means to protection reputation are lost. These
normal techniques include rate limiting, monitoring log errors, and of
course canceling accounts. None of these normal techniques will be
affective against abusive replay. With a domain-key used across a large
domain, key revocation is not practical, nor perhaps is the use of user-
keys in DNS. This does not mean there is no solution. It is clear the
revocation-identifier mechanism suggested to address this issue, is not
well understood.
Indeed there could be a centralized repository that holds the hash of
all signatures used in messages identified as abusive. The definition
of abusive is always established by this central repository. There is
no need to define abuse, this third-party must establish the criteria
for abuse.
The revocation-identifier offers an alternative. The signing domain
that receives reports of abuse based upon the revocation-identifier,
could create their own revocation-identifier "bad-list" in the same
manner as a black-hole list (which is currently done at every
connection). A negative results is short lived and uses a minimum of
resources. The signing domain would have the ability to defend their
reputation, and act quickly when there are reports of abuse. The
revocation-identifier would not depend upon monitoring DNS logs either,
as some have suggested.
To reduce the burden of doing an A record lookup to check whether a
revocation-identifier is in the bad-list, this step could be skipped
when the HELO is within the signing domain. In this case, even a
reputation check done on the HELO would not need to be repeated for the
signing domain either. By allowing this two step HELO/signing domain
check, there is a means to defend network resources from DoS attacks as
well.
A centralized hash of signatures of known bad messages simply does not
scale as well, can not be as responsive, nor will this centralized
approach provide those directly affected any say. If anything, the
problems this centralized approach could create may lead to abandoning
the use of domain-keys. This may be replaced by user-keys, or the
entire scheme dropped as unworkable.
A user-key is key delegation. It makes no sense to say some delegation
is absolutely required, but then leave those domains that don't give
each and every user their own key, no means to address replay abuse. I
don't agree that the 'g=local-part' is not a user-key. This muddling
with user-key definitions represents a failure to recognize what DKIM is
providing, an accountable domain.
Some company may want to provide an ad agency a delegated key. The ad
agency will likely be well compensated and would hope for a continued
relationship. There are any number of messages this ad agency could
send that would cause them to have their key revoked and their
relationship terminated. Publishing the message with the wrong local-
part would be likely low on the list of potential problems. I would
suggest a flag be added that indicates the key is delegated where the
selector is then treated as the revocation-identifier.
There should also be a provision to indicate that "third-part"
signatures be allowed only when within the signing domain. This would
permit a company to delegate keys to less trust-worthy entities, but
where they clearly indicate these keys represent different accountable
domains. Those with sufficient clue could quickly locate those
accountable for delegating the keys causing a problem. Allowing the
domain themselves an ability to quickly stop a problem would be the best
method to prevent future problems.
Either the domain is accountable and is both careful and responsive with
respect to key delegation, or they are not. Those that are not, deserve
the reputation they obtain. It is unreasonable to expect there can be a
policy that says only this amount of a user-key approach can be used in
DNS. Recognize that DNS can not properly support a user-key approach.
By allowing the sub-domain "third-party" signature restriction actually
better mitigates the risks of delegating keys.
DKIM does not assure the local-part! Ever. Those that wish to make this
assurance must do so independent of DKIM. One method would be provide
authenticated access to their administrated SMTP servers on port 587, or
even port 443 if needed. Otherwise, the sub-domain "third-party"
signature restriction is still much better than nothing. I would even
argue, much better than user-keys in DNS.
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim