Douglas Otis wrote:
On Jul 6, 2006, at 7:20 PM, Eliot Lear wrote:
While a service need not monolithic, the criteria established for
the RA in your example likely was based upon tangible entities. If
there was a problem, there would also be meaningful recourse. DNS
domain delegations and email interactions are orthogonal from a
trust standpoint. While DNS could be called at TTP with respect to
domain delegations (to and by often anonymous entities), with
respect to email interactions, trust is missing. When DKIM is based
upon DNS keys, either pre-arranged acceptance (white-listing), or
some other trusted third-party remains essential for secure email
interactions.
I don't see how you get here. First of all, why is trust missing
with respect to email interactions?
The CA identification process helps prevent anonymous behaviors. When
dealing with a CA or a list of CAs, the CA selection is often based
upon trust of their vetting process, hence the term trusted
third-party. As a result, the receiving party, CA, and a legal system
are better able to mitigate bad behaviors. In other words, there is a
moderate amount of recourse afforded when only trusted CAs are
consulted to secure interactions.
In the case of an SSL server certificate for commerce, the CA can be
trusted to:
- Confirm entity registration identification which includes location
- Confirm the domain is owned or controlled by the registering entity
- a 3rd party confirms the requester is an authorized agent of
registering entity
There is already a reliance on DNS because of MX records, and so
there already needs to be an established relationship between the
domain administrator and the mail administrator.
DNS provides a delegation process starting at root resolving to a name
server located by domain name. There may not be any out-of-band
information freely offered identifying the controlling entity's
identity. It is common for delegations of just one domain name to
involve from dozens to hundreds of different entities, where again
little is assured with respect to any of the delegating entity's
identity either.
A delegation process is not the same as trusting a vetting process
that specifically provides a tangible identity of the controlling
entity. In the case of DNS, there is _no_ selective trust involved.
When this process involves hundreds of thousands of often anonymous
entities, it seems rather misleading to describe that process as a
"trusted third-party." Expected to resolve a domain name is not the
same as trusted to vet the identity of the controlling entity, an
expectation invoked by the term "trusted third-party" and illustrated
by the definition.
All this is true, but this is what reputation services are for. One
could even imagine a reputation service that took registrar practices
into account. And now we really are covering old ground.
There are, typically, not countless interactions that then occur, but
the number of DNS delegations worth of interactions, and for outside
the organization that is typically two, and they're anything but
anonymous.
This represents an underestimate of the problem.
See:
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html
Limited access of whois:
http://www.pfir.org/statements/whois-access
Not anonymous?
http://www.fbi.gov/congress/congress03/farnan090403.htm
"As I’ve indicated, sometimes the Whois data is inaccurate,
incomplete, outdated, or deliberately falsified."
The whois information can _not_ be trusted even when it is available!
These statements are registrar specific and cannot be generalized.
While the level of trust one invests in DNS is always a matter of
judgment, depending on how paranoid one wants to be about each of the
delegations one could use DNSSEC, if/when it becomes available for a
given zone.
DNSSEC improves the integrity of the delegation process and exchange
of resource records. It does not improve upon extremely poor
identification vetting that might not even be available to the
recipient. The untrustworthy identification associated with DNS means
it is very misleading to describe DNS as a trusted third-party
analogous to a trusted CA.
Every problem you've mentioned with DNS can occur with CAs. Heck I run
my own. What makes you think you can trust me?!
All of this having been said, your use of the words "secure email
interactions" overstates the purpose of the method.
This comment used terminology offered by the definition provide by
Stephen. Indeed DNS does not offer a reasonable method to exclude bad
actors (secure), where a trusted third-party does.
Reiterating, every problem you state really has nothing to do with DNS
but with registration. That problem is universal, regardless of
mechanism. To be fair CAs have a few more gizmos to play with, but the
notion of delegation and registration remains the same.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html