On Sun, 2005-03-06 at 19:57 -0500, Andrew Newton wrote:
On Mar 6, 2005, at 5:45 PM, Douglas Otis wrote:
A requirement that the opaque identifier represents only a single
domain label would keep this mechanism simple. Allowing use of
multiple labels could provide an administrative advantage by being
able to kill a single message rather than a whole account, as
Phillip suggests. The selector could be included within this path
as well to allow immediate reuse of account numbers, as example. An
opaque identifier definition would allow greater complexity without
constraints. In an effort to ensure simplicity, one or two labels
could be a limit. This is a trade-off.
What is wrong with just making the revocation ID any valid domain name?
For there to be an advantage allowing multiple labels, there would need
to be a lookup made at every node, such that this adds to the overhead.
I would rather keep this simple to reduce complexity and overhead.
Perhaps limit this to one or two labels.
That makes this really simple and puts the choice of complexity for
revocation in the hands of the admins.
There is potential for there being an impact, where each node has to be
assured to be free of an A record.
There is another cost savings, by authenticating the HELO and finding
that it is within the signature domain, a revocation record check could
be skipped. Even when everyone published revocation-identifiers, the
traffic should remain small by being generated when the message is
being forwarded or sent unaltered from a list server.
I'm not sure this is a good idea. By attaching the HELO identity to a
subpart of the signature domain, doesn't this impact forwarding?
I am not sure I understand this question.
The MSA has the advantage of already making a determination before
allowing the message to be sent and, by convention, the HELO should be
within the domain of the signature (a child of the signature domain).
Any MTA, with a HELO within the signature domain, must ensure signed
messages being sent have been checked for revocation. By relegating
revocation checks to those MTAs with authenticated HELO domains found
within (a child of) the signature domain, the need to do a revocation
check is kept to a minimum. Both the signature and the MTA should both
be under the same administrative authority. It would only require that
a common rule be applied that any HELO not within the signature domain
receives a revocation check.
When the message is forwarded, the HELO would then not be within the
domain of the signature (or perhaps not even authenticate), and
therefore a revocation check would be required. When the message is
sent directly from the MSA with an authenticated HELO domain contained
within the signature's domain, it can be presumed the MSA knows whether
the revocation-identifier was valid and would have only sent the message
when the revocation-identifier was confirmed valid.
Also, it requires the HELO identity to be a subpart of the signature
domain which isn't true even in a lot of hop-by-hop cases.
By establishing a convention that makes good use of the HELO, a reduced
overhead becomes possible. Not adhering to this convention requires a
revocation check, which is nearly identical to an RBL check anyway.
The HELO is also required for DoS protection. DoS checks can only be
safely done using authenticated entities and, by being able to use a
domain name in both cases (HELO and signature), another overhead savings
is made possible. HELO and signatures overcome the tyranny of the IP
address as basis for reputation.
Anything that could corrupt a DoS database destroys its protective
utility. An entity not authenticated (such as a mailbox-domain within a
header or parameter) allows the DoS database to become corrupted by
spoofed mailbox-domains from shared MTAs, as example. Of course when
done through third-parties as a reputation service, legal issues also
become another factor in this protection. Only applying reputation to
authenticated entities protects consumers as well as the integrity of
If you are suggesting this is an optimization, I'm not sure it is
saving much if anything.
Signatures can not protect network resources. The entire message and
CPU resources is consumed for a signature. The HELO can be effective
within a single DNS lookup before a message is even exchanged. The HELO
can protect network resources and is needed to play this role. Again, a
mailbox-domain can not be authenticated which prevents any reliable
assessments to be made as a basis for protection.
It also seems to be introducing an extra step adding to overall
I have always said that checking the HELO is to protect the networks.
Whereas the message signature allows acceptance based upon the
originating domain of the message, and also allows complaints to be
directed to the administrator able to take immediate corrective action.
The revocation record would acknowledge the administrator's response to