Re: opaque-identifier scaling (was: Re: [ietf-dkim] ebay / eboy)
2005-11-01 20:19:46
On Nov 1, 2005, at 4:31 PM, Stephen Farrell wrote:
You keep mentioning it so let's see how it works...
I have read it. I continue to believe its analagous to a
serialNumber with the MTA as a signer being analagous to a CA.
Analogous in concept, but this would not represent the same level of
effort.
Requiring a signing domain to maintain such a revocation list
may be onerous. Say if I get a (bunch of) bogus accounts in order
to DoS this revocation scheme?
I would assume that setting up an account would be roughly as
difficult. There can be third-party service providers to publish
revoked opaque-identifiers within seconds of being notified, if this
becomes too problematic for the domain selling such large numbers of
accounts to Bad Actors. Of course, such a domain should be able to
automate this process themselves. The amount of data that would need
to be published would be small, and would only be queried when the
channel appears to have changed characteristics.
Do you have any information about how your approach scales in such
a case?
On a daily basis, our dynamic lists fluctuate in the millions,
updated with an aggregate feed of hundreds of thousands changed by
the minute continuously. There are several factors that may delay
this process, while there are also methods to avoid these delays. If
publishing a revocation list becomes a problem, there are those able
to handle this task on a timely basis. Unlike the centralized
approach being described that offers services to a substantial
portion of the world's receiving MTAs, the opaque-identifier
revocation list would be distributed at each sending domain, where
even then only a small portion of the messages would require a
revocation check.
About other new DoSes it may create?
As this is being queried in limited cases, the increased load should
be small. There should be less concern at the server. As this
mechanism should be used in conjunction with CSV and reputation,
IMHO, I can say this will mitigate DoS attacks. : )
About how it might affect the DNS load or capacity for the
DNS server of a mail server from a domain under attack from inside?
I would assume that the domain's reputation has been checked first.
Of the limited portion of traffic that will generate revocation
queries, the majority of these these should be a small negative
results held within the DNS resolver for a brief period
(implementation dependent). Compared to domain-keys, this would be
negligible (below a percentile). The alternative of publishing a key
for each sender, with perhaps short TTLs, would have a far greater
impact on several existing implementations. While there are
remedies, care should be taken with respect to the change a new
scheme introduces. This revocation scheme should not represent an
impact greater than the use of a limited number of keys. This of
course should be compared to other methods that address the message
replay abuse problem, assuming there are practical alternatives. : )
(And thus publishing many revocations.) Simply asserting that there
are no problems in this respect isn't really credible.
There are many people that have found that publishing these types of
lists are not difficult. This would be comparable to the many
existing black-holes lists. There would be a major difference
however. This approach would be distributed whereas black-hole lists
are centralized and therefore must handle the load for thousands,
compared to one domain.
There are more email messages in the world than x.509 certs (so
the differing validity periods may not be a saving grace), and
and I know that maintenance of CRLs is a problem for CAs. I really
can't see where you've found a magic bullet that makes your
idea that different.
Consider the timeframe involved and how it should relate to the
revocation of an account. Of course there could be some type of
prefix added that indicates the same actor, but with a problem resolved.
Having said that, the idea may be worth exploring,
but that's not really going to happen if its only viable as the
"one true answer" - there isn't one and presenting your idea that
way is a sure-fire way of just annoying people.
Unfortunately, there has been some insistence systemic problems can
be ignored, and perhaps why a review was considered a good first
step. I have pointed out omissions where there is much left unsaid.
I want to see a workable solution, and am willing to accept better
ideas.
I do have a bias. It would be most unfortunate for DKIM to become
yet another bloated, impractical, unfair, email-address authorization
scheme. There are serious problems that DKIM can mitigate, but these
problems have little to do with what email-address is authorized for
a particular message. Although detecting email-address related fraud
can be assisted by a DKIM signature, this should be seen as a
secondary attribute handled by a completely separate process.
My intent is not to annoy, especially when dealing with so many
highly talented people. I do however come at this problem with a
different perspective. Providers are often needing to respond to
problems, and are looking for mechanisms that will minimize their
efforts. In that sense, there may be a bit of conflict involved, as
often these solutions will not meet the needs of the email-address
domain owner. These are people that must be considered, as unfairly
removing their ability to communicate will ultimately prove very
costly in many ways.
> Even adding the
Sender header will create an inordinate number of support calls,
where even still, the message may be rejected or deleted.
Evaluating acceptance of the message should be based upon the
signing- domain.
Perhaps yes. Perhaps as an option. Perhaps not.
Remains to be proven IMO.
Tripp Cox of Earthlink should be able to clarify this issue based
upon their deployment experience of DomainKeys.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|