ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-10 21:41:17

--- 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?

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.

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?

If there is no caching, why not call-back to the submission domain and ask
whether the message-id is still valid? Won't that achieve the same result? 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?

As a final question, why not check a revocation list against the actual email
address? 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?

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.


Mark.


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