DKIM TTPs (was Re: [ietf-dkim] editorials and nits)
Eliot Lear
lear at cisco.com
Fri Jul 7 13:59:18 PDT 2006
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
More information about the ietf-dkim
mailing list