On Thu, 2005-02-10 at 20:41 -0800,
domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
wrote:
--- Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
matter of extricating just a few bad accounts. No provider, large or
small, is able to prevent "replay" attacks without an additional
mechanism. Message signatures and an opaque identifier added by the
domain authentication process, together with published revocation
records, is a means to abate "replay" abuse. Reputations could thus be
retained for both large and small domains. Why not add an optional
opaque identifier?
I'm going to guess Doug, that you kinda like these opaque identifiers. Yes?
By opaque, it means the sender knows the significance of the identifier.
Ignoring value inherent in preventing "replay" abuse, for cases where
identifiers are persistent, correlation of abuse becomes easier.
Specific sources can be tallied without analyzing SMTP, address
assignment, and access server logs. Overall, the identifier reduces
expenditures required to address abuse by all parties involved. These
identifier based savings would not impose constraints upon the consumer,
nor change the way mail is used.
However, I'm assuming that you need to make a query against such identifiers
to
ensure they are still valid. Yes? If no, can you explain, in simple
mechanical
terms, how these opaque identifiers are used by the recipient? If you could be
kinda enough to spell it out, that'd be handy as I'm a little slow.
This would be an option that could be employed when "replay" abuse is
found damaging a domain's reputation. Signatures offer an authenticated
identity suitable for assessing reputation, independent of the IP
address reputation now used. Signatures with a revocation mechanism
would act as a disincentive for compromising systems or accounts as a
means to usurp the reputation of the domain's signature. This could
serve as a type of email "lojack" system. Signatures offer the
possibility of localizing efforts in identifying abuse.
Signature reputation can not be protected through account controls nor
punitive measures which block entire domains used by the public.
Signatures offer server independence, but for the signature to have
value with respect to reputation, the domain must be able to control, at
their option, the implied authorization of the signature.
Does a query against the opaque identifier need to be made for every inbound
email? If yes, what does that do for caching of opaque identifier query
results? Does it mean that there is no caching?
See RFC2308. Not publishing a record does not mean negative results are
not normally cached. Compared to per-user keys, there is no additional
payload, and TTLs are determined by the recipient. For accounts that
are revoked, the A record should have a TTL comparable to that of the
key or fingerprint. Previous key information and the location of the
identifier information would normally exist within the cache. Whereas
single identifier queries may be made on a per message basis, unless a
message with the same identifier was recently received. The recipient
would be able to trade cache size against DNS traffic.
A negative response would be a small payload, and is the method already
employed for IP address reputation assessment. The rate normal mail is
combined within a single session is much lower than that with spam, and
should approach a message per session, making such use comparable. A
record returned would positively indicate abuse, whereas no key could
mean this may be just a stale message.
If there is no caching, why not call-back to the submission domain and ask
whether the message-id is still valid?
There is negative caching normally, and a new call-back mechanism would
be possible, but what I am suggesting already exists and should be
equally effective.
Won't that achieve the same result?
Yes, you could create a new service with similar results. If you
decided the most responsive approach was achieved using UDP, then there
are firewall issues, in addition to deploying a new service.
Then an ISP/service provider can revoke messages.
Also, can you explain the fundamental difference between an opaque identifier
and a per-user key? What's the performance benefit? If a recipient has to
query
for the opaque identifier, why not query for the per-user key?
There are some differences.
1) A key versus a negative response has a much larger payload.
2) A key's life-span is determined by the sender.
3) A key must expire and have a comparable but smaller TTL.
4) An opaque identifier can be unique per message for anonymity.
5) An opaque identifier allows more responsive abatement.
6) An opaque identifier query can positively indicate abuse.
Once a domain decides they have a "replay" problem, reacting to this
situation would be much easier by offering an opaque identifier.
Deployment of keys must consider publishing of two or more keys to
prepare for key expiration. For larger domains of 20 million users, two
keys per user may require 14 GB of data. This much information becomes
a deployment issue, as memory based data is essential for
responsiveness. For the opaque identifier, there would still be the two
domain keys and a few blackhole-listing A records, which requires but a
few thousand bytes of information in comparison. Opaque identifier
deployment would be possible, even when done manually. The difference
represents 6 orders of magnitude reduction of data exchanged.
As a final question, why not check a revocation list against the actual email
address?
A convention that uses an identifier has several advantages. It would be
unwise to publish email addresses due to possible abuse. Your customer
may not appreciate the resulting influx of mail. The domain signing the
message may not be directly associated with a mailbox-domains within the
message.
Could I not query mail-abuse.org and ask the question "has dotis" been
revoked? Taking that to a degenerate case, why not connect to the MX for
mail-abuse.org and ask whether 2821.RCPTTO dotis is accepted?
This approach is being used by a few today, often dropping connections
mid-session. Not very expedient from a performance perspective and
would not scale well. One UDP query versus an iterative TCP session?
Functionally I'd like to understand the unique characteristic of your beloved
opaque identifiers that can't be achieved with alternate mechanisms that incur
similar costs.
This offers an alternative when considering the impact upon the
infrastructure. While having per-user keys could address a "replay"
abuse problem, the impact upon resources and deployment would be much
greater than would the use of opaque identifiers. Per-user keys would
still not be as responsive. These are not similar costs when they
represent such huge differences in the amount of data required to
support per-user keys versus opaque identifiers.
Signature have the potential for safe reputation assertions and to act
as powerful deterrents against desktop attack. This potential can only
be achieved when use of the signature is guarded, and a violation
immediately detected. Protection and abatement relies upon ensuring the
security of the signing SMTP server and not each desktop, but only when
signature revocation is possible.
-Doug