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