Re: Off-tree validation

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 13:13 12.04.2000 -0400, Edward Lewis wrote:
>The reason I ask is that off-tree validation appears to be hard to secure.
>Assuming a resolver will trust a chain of keys up to a trusted root,
>imagine what would happen in the above example if certifier maliciously
>copies the labs zone, replaces the true apex KEY set and signs the false
>set itself.  The zone has been "zone jacked" and certifier can do with it
>what it wants.

Apex replacement wouldn't work.

[boring lecture - anyone who has read Scneider can skip this]

In any signature-based system, there has to be a key that the verifier 
trusts unconditionally (in PGP it's the user's own key; in hierarchical 
DNSSEC and the late unlamented PEM it is a worldwide "root" key; in 
Internet Explorer, Microsoft has taken the trouble to trust about 107 
different keys on your behalf. Check Tools/Internet 
Options/Content/Certificates/Trusted Root Certification Authorities for the 
list if you don't believe me).

If you can compromise that key, or get the resolver to trust an 
untrustworthy key, you can get him to believe anything.

Off-tree validation is important because it allows a set of cooperating 
zones to be *more* secure (more expensive to attack) than their parent 
zones (or the root key). But it doesn't help anyone outside that set.

The difficulty with off-tree signing (or any nonhierarchical signing 
method) is that you replace a tree-shaped graph of signatures and keys with 
a general graph; finding a path from the record you want to check to a key 
you trust in a general graph the size of the DNS is not particularly quick.

[back to topic]

the attack that works against off-tree validation is this, I think:

          APEX
      /        \
   zoneA     zoneB
     |         |    \
     |         |     \
   zoneAA    zoneBB   zoneAA
    (real)    (real)   (fake)

where all the lines are "parent has signed child's key", but the names
don't have to match up.

The problem is that KEY records don't include enough policy info; a SIG
says "I think this is a valid key", not "I think this is a valid key for
signing zoneBB, but not for signing zoneAA".

So if you want secure off-tree validation, you'd better trust the first key,
or have information not available in the current DNS specs.

Sounds right?

                      Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no