Subject: [dane] Delegated Services Problems

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Jul 2011 11:54:49 -0700

I have been going through the delegated services cases (3.4 in use-cases)
and I have decided that I don't understand enough to think that they are
correct.

1.  Alice maintains DNSSEC control of the tree and delegates a service to
Oscar.  This case is straight forward from Alice's point of view.  Alice
maintains all DNS records and the coordination needed if either the
addresses or the certificate chain changes is well understood.

2.  Alice  delegates a sub-domain to Oscar and Oscar becomes the DNSSEC
authority for the sub-tree.  This case is also straight forward, the use
case document is missing the fact that if the DNS keys for Oscar change then
Alice needs to be notified of this. 

3.  Alice just does a CName reference to Oscar for the service and Oscar is
the full authority.  Again this case is straight forward and requires zero
coordination between Alice and Oscar at all.

4.  Alice keeps the DNS records but delegates the address records to Oscar.
With my limited understanding I can think of a couple of ways that this
could be implemented.

4a.  Alice delegates www.alice.com to Oscar and Oscar delegates
_443._tcp._www.alice.com back to Alice.   In this case things work as
expected, but Alice does not have any insurance that Oscar is doing the
delegation back except by doing a routine name resolution and seeing where
things go.

4b. Alice uses a CName to Oscar and Oscar delegates back to Alice.  In this
case alice.com contains a CName to alice.oscar.com and Oscar delegates
_443._tcp._alice.oscar.com back to Alice.  Note that one would not be able
to CName to Oscar.com as this would mess up both Oscar and anyone else that
Oscar is giving services to.

4c.  Alice uses a CName to get the A/AAAA record for the service, but the
TLSA records are kept in Alice's DNS tree.  This changes the way that I have
always thought that the DNS lookups will occur for DANE and thus needs both
consideration and documentation if it is to be used.  NOTE:  This is the
only method that can be used by Alice if she really wants to keep full
control of the certificates/keys and trust anchors used by Oscar.

    Look up for Addresses:
        www.alice.com - returns nothing
        alice.com - returns CName to Oscar.com
       Oscar.com - returns AAAA record for server.

  Look up for TLSA records:
     _443._tcp.www.alice.com - returns nothing
     _443._tcp.alice.com - if returns TLSA records - then use them
    Else
   Use the CName record from alice.com
   _443._tcp.oscar.com - returns TLSA records.

I am sure that the above sequence of what things to look up is both
incomplete and wrong, but it will give me enough rope to show the sequence
of events that I want to see happen.   The address look ups proceed as
currently defined.  However for the TLSA look ups a new sequence of events
is done.

1.  Start by using the ORIGINAL address  you were looking for and make the
TLSA modifications for it. 
2.  Resolve for a TLSA record - if found then stop
3.  Resolve for a CName record - if found then change to the search address
to the TSLA modifications on the new CName record go to step 2
4. Move to parent in tree - if "too high" stop
5. Go to step 2

Jim