Subject: [dane] TLSA RRset and CNAME question

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Mar 2013 23:53:08 +0000

Suppose a query a known signed zone:

	Q: _25._tcp.mail.example.com. IN TLSA ?

and I receive a signed CNAME referral:

	A: _25._tcp.mail.example.com. IN CNAME 3.1.1._tlsa.example.edu.

and suppose further that the example.edu zone is unsigned with FWIW
an insecure (zone is not signed) TLSA record published there:

	3.1.1._tlsa.example.edu. IN TLSA 3 1 1 <hash and eggs>

Is this a a case of "no TLSA records" or "no usable TLSA records"?

The domain owner of the secure zone thought they were publishing
TLSA records, so one might think (draft-ietf-dane-srv) that one
MUST use TLS for this service (be it with whatever non-DANE policy
applies when one does that).

On the other hand, the error is rather similar from an implementation
sanity viewpoint to a failure to find validated records, as opposed
to use of parameters not understood by the client, ...

The simplest stub resolver logic for DNSSEC when chasing CNAMEs is
to return the boolean AND of the validation status of the final
answer with the status for any CNAMEs chased along the way. All
this is nicely layered inside a library (so the application does
not have to do the chasing itself), and now it is impossible to
distinguish between the first zone being unsigned, and some
intermediate CNAME being unsigned.

So to retain some implementation sanity I'd like to vote for "not
found" rather than "unusable", though the owner of "example.com"
may be surprised by the outcome, it is IMHO his fault for CNAMEing
the TLSA at a domain outside his control.  We can reasonably hope
such cases will be rare, and that domains once signed, will mostly
tend to stay signed.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Thu, 14 Mar 2013 06:05:00 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> Suppose a query a known signed zone: ...  and I receive a signed
VD> CNAME referral: ...  and suppose further that the example.edu zone
VD> is unsigned with FWIW an insecure (zone is not signed) TLSA record
VD> published there:

My understanding of the consensus is that, if anything in the chain is
unsigned (as opposed to bogus), then any tlsa records should be ignored
and the connection should progress as if dane were not there at all.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: John Gilmore <[email-masked]>
Date: Thu, 14 Mar 2013 11:21:06 -0800

> Is this a a case of "no TLSA records" or "no usable TLSA records"?

This is a case of "no TLSA records".  That's a CNAME record, not a
TLSA record.  If the domain admin wanted to put a TLSA record there,
they know how to do that.

There is nothing magic about the _25._tcp subdomain names.  Using
them for a CNAME (or an A record or anything else) does not indicate
a desire to use TLSA records.

	John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 15:47:06 -0400

> they know how to do that.

Not if there's a CNAME there, they don't.  You can't put a TLSA record
there if there's a CNAME.

> a desire to use TLSA records.

But if there's a CNAME with a TLSA record at the target, presumably
you ought to use that TLSA record.  No?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2013 20:10:20 +0000

> they know how to do that.

Yes, but the domain will still be surprised, because their *intent*
is to indirectly leverage a TLSA record stored elsewhere in the DNS.
For example:

  _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl.
  3.1.1._dane.nlnetlabs.nl.   IN TLSA  3 1 1 0D1F...

This case the CNAME points to a record in the same zone, but real
users will do stranger things.

> a desire to use TLSA records.

I agree with the logic, (this is the answer I was hoping for and
expecting).  So domain owners will need to be cautioned about the
risks of CNAMEs intended for use with TLSA records.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2013 20:13:45 +0000

> there if there's a CNAME.

John clearly meant in place of, not in addition.

> you ought to use that TLSA record.  No?

Yes, if both are validated, but not otherwise, in particular a
validated CNAME to a not validated TLSA RRset is not validated and
the combination bevahes indistinguishably from "NODATA", undoubtedly
some folks will keep getting surprised by this.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 16:26:37 -0400

Oh, sorry, I'm dim.

> some folks will keep getting surprised by this.

Perhaps.  I'd call that a "feature", though.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 14 Mar 2013 22:42:57 +0000

Hi Andrew, folks,
it's a feature only if documented.
This thread has been useful (certainly made me think), so please can someone document this?
Maybe a "care and feeding of ..." document for this menagerie of RRs would be useful.
We did an "Experiences" doc for ENUM to try to capture the holes various implementors fell into, and ENUM's trivial by comparison.

all the best,
 Lawrence