ietf-dkim
[Top] [All Lists]

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