Sam Hartman wrote as an individual contribution:
However there is a similar issue with DKIM. It's not clear what
policies a medium sized ISP could adopt to avoid being subject to such
an attack. It's not clear how you could maintain a reputation while
still defaulting to providing service to anyone who wants an account.
There are a few possibilities:
- There was a suggestion of a "revocation ID" that could optionally be
part of the signature. If present, the verifier would need to query the
originating domain (DNS again, probably...) to see if there is a record
indicating that the given revocation ID has indeed been revoked (absence
of a record indicating no revocation). ISPs would potentially apply a
different revocation ID per customer. This warrants further study; if
DNS is used for this, we need to think about both the transaction load
and the amount of negative caching that would need to be done.
- As a business model, ISPs might consider message signing to be a
premium service, for which they either charge extra or vet their
customers more thoroughly. "Free" accounts might not get their mail
signed or might get it signed by some key with a potentially more
dubious reputation.
- Operationally, DKIM might be used with other mechanisms (SenderID/SPF
or CSV for example) and an affirmative result from both would probably
be a better indication that a replay attack is not taking place.
Messages which pass DKIM but fail the other mechanism might be subject
to additional scrutiny.
Do we care? Is this acceptable to the operations communities?
I care. This is an example of where signature-based mechanisms aren't
perfect, but nothing is. Nevertheless, I feel that they still add
significant enough value to be worthwhile. But I'm not an operations
guy, so we need their comments as well.
-Jim