On Fri, 2005-01-14 at 00:39 -0500, James M Galvin wrote:
For me, John's last sentence is the most important point in all of this
discussion:
> The most that a signature can do is to identify the responsible party.
> There's no point in adding cruft that attempts to go beyond that.
So, I ask, why are we trying to do more than find the immediately
preceding responsible party?
It is a small step, but it's a good step, and there will be more steps
later. The place to start is to push back, one hop at a time.
If I knew the immediately preceding responsible party for a message, I
could better manage my black/white/grey list. That would be great step
forward. And if each hop simply asserted (cryptographically of course)
what was received from its preceding hop we would have a trace.
Something akin to received lines with a signature, or a "long hop" as
it's been called before.
In essence, the network level protection schemes offer the last hop
protections. If last hop authentication was used consistently, there
would be a mean to trace this process. This works relatively well, but
is a rather blunt instrument. Many abusers "hide" in the crowd. They
manage to get accepted by high profile providers and blaze away. It is
very painful to use the last hop as a selection criteria alone. There
is a vital need for the network level of protection, but we also need
more if to be effective at dealing with the problem. Network level
protection is moving to utilize the name space, in addition to the
address space.
The signature offers a means for the high profile provider to retain
their reputation by being able to squelch abuse bearing their signature,
irrespective of the last hop. This can be seen as a surgical
instrument. It can cut out just a few of the bad accounts rather than
treating the whole domain or the last hop as a group. It applies to the
domain granting initial access. I see the "network" and "access" level
protection schemes working together to become effect deterrents when
used in conjunction history information.
For the signature scheme to be effective, the ability to block a bad
account should be affective immediately and not need to wait for a key
to expire. This could be done by adding a unique account identifier to
the header such as u=0001237. This would work differently from that of
a selector. With this information offered, the recipient would then
have a choice of preforming a query on _arl.<unique account
identifier>.<domain>. If a record is returned, the message can be
rejected.
While most domains would not need such a feature, for those domains that
have many accounts, this feature could prove useful. Distributing keys
for every account would become rather costly. DNS tends to use about 4
times the memory of the data stored to ensure fast responses. Keeping
the DNS cache on a diet seems like a good idea, as it has a thyroid
problem.
There could be some first letter conventions used in this identifier to
classify the type of account. i = individual, c = commercial, g =
group, l = list, etc.
-Doug