Subject: Re: [dane] Delegated Services Problems

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 17:40:01 +0200

Jim,

On 18. 7. 2011, at 20:54, Jim Schaad wrote:

> 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.

Just to be sure.  When you say delegates you mean:

www.alice.com IN NS ns1.oscar.com
www.alice.com IN NS ns2.oscar.com

?

> 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.

CNAME applies only to owner, so if Alice uses a CName to Oscar it applies only
to 'alice.com' and hence the Oscar cannot delegate anything back to Alice.
[Ignoring the fact that you normally cannot create CNAMEs at second level domain.]

E.g. it's valid zone to have

alice.com IN CNAME alice.oscar.com
_443._tcp.alice.com IN TLSA <record>

To tell the truth I think that 4b and 4c is same.

> 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

I still fail to understand what is wrong with simply doing:

If not 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

I think that this is just a big security rathole.  The whole purpose of DANE
was to keep control close to domain owner and this steps would allow Oscar
to control the Alice TLSA records without her consent.  Please let's not go
this way.

> 4. Move to parent in tree - if "too high" stop
> 5. Go to step 2

I would like to keep these two issues separate (the "CNAME" and "DANE for whole domain").

The fact that the application doesn't know what is "too high" (and we see the same
problem with cookie domains) and not only it doesn't know, but it also cannot know
even with parsing the whole DNS tree and comparing the domains at zonecuts.

We have this as an open issue #23 (http://tools.ietf.org/wg/dane/trac/ticket/23)
and we will talk about that, but let's not make the CNAME/wildcards more complicated,
please.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 3 Aug 2011 07:47:15 +0200 (CEST)

Sorry for jumping in on the detail, but

alice.com. IN CNAME alice.oscar.com.

is most likely invalid because of "CNAME and other data" :
If alice.com. is a delegated name in com. (NS records exist),
then the zone file for alice.com. already holds SOA, NS records and most 
probably MX-record(s).
Their existence forbids the creation of a CNAME at that level !

Kind regards,

Marc

-----Original Message-----
From: Ondřej Surý [mailto:[email-masked]]
Sent: 02 August 2011 05:40 PM
To: Jim Schaad
Cc: Paul Hoffman; [email-masked]
Subject: Re: [dane] Delegated Services Problems

...

> Oscar is giving services to.

CNAME applies only to owner, so if Alice uses a CName to Oscar it applies 
only
to 'alice.com' and hence the Oscar cannot delegate anything back to Alice.
[Ignoring the fact that you normally cannot create CNAMEs at second level 
domain.]

...

O.

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 3 Aug 2011 09:08:50 +0200 (CEST)

For clarity,
Ondrej just pointed out he'd also indicated that CNAME is normally not 
possible,
that line had escaped my attention.

Marc

-----Original Message-----
From: Marc Lampo [mailto:[email-masked]]
Sent: 03 August 2011 07:47 AM
To: 'Ondřej Surý'; 'Jim Schaad'
Cc: 'Paul Hoffman'; [email-masked]'
Subject: RE: [dane] Delegated Services Problems

Kind regards,

Marc

-----Original Message-----
From: Ondřej Surý [mailto:[email-masked]]
Sent: 02 August 2011 05:40 PM
To: Jim Schaad
Cc: Paul Hoffman; [email-masked]
Subject: Re: [dane] Delegated Services Problems

...

...

O.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Aug 2011 19:03:33 -0700

> From: Ondrej Surý [mailto:[email-masked]]
> Sent: Tuesday, August 02, 2011 8:40 AM
> To: Jim Schaad
> Cc: Paul Hoffman; [email-masked]; [email-masked]
> > 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.
> >
> > With my limited understanding I can think of a couple of ways that
> > this could be implemented.
> >
> > 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.
> 

Yes, I had to look it up since I don't know DNS very well but this is what I was  saying

> 
> > 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.
> 
> only to 'alice.com' and hence the Oscar cannot delegate anything back to
> Alice.

What I was doing here was
www.alice.com IN CNAME alice.oscar.com
_tcp.alice.oscar.com IN NS ns1.alice.com
_443._tcp.alice.oscar.com IN TLSA <record>

> > 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:
> > 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.

Nothing is wrong with that, it was just that my understanding may be flawed.  I thought that the point might be to find something in a more general way.  This could be completely mistaken.  I was also under the impression that one did not need to prefix the TLSA records and the system could find them.  Thus one could have the records at

_443._tcp.alice.com
alice.com

and if the first did not exist then looking them up at the second location might find useful ones.  This would allow for a single set of records to be published for all services and then override as necessary (i.e. you would not need to do *.alice.com and publish there).

> 
> > 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
> 
> I think that this is just a big security rathole.  The whole purpose of DANE was
> to keep control close to domain owner and this steps would allow Oscar to
> control the Alice TLSA records without her consent.  Please let's not go this
> way.
> 

An acceptable answer - which means a higher degree of cooperation between Oscar and Alice than might currently be the case.

> > 4. Move to parent in tree - if "too high" stop 5. Go to step 2
> 
> The fact that the application doesn't know what is "too high" (and we see the
> same problem with cookie domains) and not only it doesn't know, but it also
> cannot know even with parsing the whole DNS tree and comparing the
> domains at zonecuts.
> 
> We have this as an open issue #23
> (http://tools.ietf.org/wg/dane/trac/ticket/23)
> and we will talk about that, but let's not make the CNAME/wildcards more
> complicated, please.

I was just trying to be complete and make sure that all of the cases were covered.

Jim

> 
> O.
> --
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Aug 2011 19:10:12 -0700

Fine - make it 

> Sent: Tuesday, August 02, 2011 10:47 PM
> To: 'Ondrej Surý'; 'Jim Schaad'
> Cc: 'Paul Hoffman'; [email-masked]
> If alice.com. is a delegated name in com. (NS records exist), then the zone
> file for alice.com. already holds SOA, NS records and most probably MX-
> record(s).
> From: Ondrej Sur  [mailto:[email-masked]]
> ..
> ..