[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems

On Sat, 11 Aug 2001, Michael Thomas wrote:
>  > > [anonymous encryption]
>  > We thought about that, but decided that some authentication was better
>  > than none, especially since it would upgrade transparently...
> 
>    Well... How is this especially different than just
>    using self-signed certificates and having a wide open policy?

The transparent upgrade to full security is important.  As I said before,
there's an important difference between temporary and permanent security
holes.  The nice thing about having DNSSEC verify the provenance of the
public keys is that instituting this requires no changes to the protocol
*or the protocol software*.  Going from self-signed certificates to a
certificate signing chain would.

Before too very long, it *will* be necessary to secure DNS, whether that
is done by the current DNSSEC or by other means.  Why duplicate that work
in each application? 

>    I guess what bothers me is that you are expecting to
>    use DNS as a directory service for certs which it
>    wasn't really intended for...

What was DNS "really intended for"?  RFC 1034 (emphasis added):

   - The costs of implementing such a facility dictate that it be
     generally useful, and not restricted to a single application.
     We should be able to use names to retrieve host addresses,
     mailbox data, ***and other as yet undetermined information***.

DNS is for retrieving information about names.  Using it to obtain public
keys or certificates (please distinguish between the two, they are not
synonymous) for names seems perfectly reasonable.  Which is why DNS now
has KEY and CERT records. 

>    ...thus making an already
>    complicated situation even more complicated, but
>    not changing the fundamental situation (PKI are hard).

I tend to think that today's PKI are harder than necessary, partly because
they are trying to reinvent the DNS wheel and doing it badly.  As with the
messes that arise in application-level encryption, much of this is
spurious, arising because we have delayed too long in securing the basic
services (IP, DNS).  If DNS had been a secure source of KEY records (etc.)
all along, people would wonder why all the fuss about PKI.

>    I guess that I view that there's probably an 80/20 rule
>    here which is being missed: *most* people aren't going
>    to go to the lengths of creating an active MITM attack
>    to snoop on boring old every day conversations.

One must distinguish carefully between two different categories of people:
the users, and the attackers.  It's not unreasonable to aim protocols at
80% of the users, but that means those users should be secure against very
nearly 100% of the attackers.  It only takes one aggressive attacker to
put many users in jeopardy. 

Most especially and particularly, there are quite a number of countries in
the world where you can be 100% sure that the government will be an
attacker, *because it already is*.  And it has the cooperation, willing or
unwilling, of the ISPs... so MITM attacks will not be difficult to mount.
This is an important type of attacker. 

>    ...Trying to insert
>    an upgrade path back to the mythical global PKI rather
>    misses the point: if there were such a beast, we could
>    should be able to use IKE as-is...

Actually, we *are* proposing to use IKE pretty much as-is (gross though it
is).  Nothing in opportunistic encryption involves changes to IKE. 

                                                          Henry Spencer
                                                       henry@spsystems.net
Follow-Ups: References: