Subject: [dane] The Curse of The Same, was CNAMES and Wildcards

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 00:13:08 -0000

This discussion reminds of an equally unsatisfactory one we had a few
months ago about what it would mean for two TLDs to be The Same.  So
here's some examples:

Example 1:

www.foo.com CNAME www.bar.com
www.bar.com A     1.2.3.4
_443._tcp.www.bar.com TLSA "bar stuff"

Should an application using DANE and looking at www.foo.com find the
bar stuff?

Example 2:

www.foo.com CNAME www.bar.com
www.bar.com A     1.2.3.4
_443._tcp.www.foo.com TLSA "foo stuff"
_443._tcp.www.bar.com TLSA "bar stuff"

Is this valid?  If so, should an application using DANE looking at
www.foo.com find the foo stuff or the bar stuff?

Example 3:

www.foo.com CNAME www.bar.com
www.bar.com A     1.2.3.4
_443._tcp.www.foo.com TLSA "foo stuff"

Is this valid?  If so, should an application using DANE looking at
www.foo.com find the foo stuff or nothing?

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Aug 2011 20:44:34 -0400

1) "bar stuff"
2) "foo stuff"
3) "foo stuff"

Telling everyone that they are only allowed (2) is going to fail in
deployment.

Making analogies to SRV really does not help because SRV is itself an alias
and so most of the uses for CNAME can be satisfied using the domain name
mapping of SRV itself. Even so it is not possible to use SRV with wildcards
and that casuses operational issues.

On Mon, Aug 1, 2011 at 8:13 PM, John Levine <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Website: http://hallambaker.com/

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 2 Aug 2011 07:46:00 +0200

> Should an application using DANE and looking at www.foo.com find the

An application using DANE would not look up www.foo.com, as this name does not carry any TLSA records. The application would look up _443._tcp.www.foo.com, which returns nothing.

> www.foo.com find the foo stuff or the bar stuff?

Yes, this is valid. See my not on SNI in another thread (foo & bar may have different certs at the same endpoint).

> www.foo.com find the foo stuff or nothing?

Yes, it will find foo stuff. If you try to look at bar, you will find nothing.

	jakob

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 09:46:19 +0200

> months ago about what it would mean for two TLDs to be The Same.  So

But this is not same as the name sameness.  www.foo.com and www.bar.com
are different from DANE perspective.

> Should an application using DANE and looking at www.foo.com find the

No.

> Is this valid?

Yes, it is.

> If so, should an application using DANE looking at

It should find the foo staff, because it is looking for www.foo.com
and not www.bar.com.  The same applies to HTTP - you ask the HTTP
server for www.foo.com and not for www.bar.com.  Same logic applies
for DANE.

From DNS perspective this case is really same as:

www.foo.com A     1.2.3.4
www.bar.com A     1.2.3.4

You don't look at CNAMEs in the application.

> Is this valid?

Yes, it is.

> If so, should an application using DANE looking at

Application will find the _443._tcp.www.foo.com if
it is looking for www.foo.com.  Applications looking
at www.bar.com will find nothing.

Fortunately the usage of prefix has saved us the CNAME-only
problem and I am happy to sacrifice wildcards as one use case
where DANE cannot be used.  Well, to be absolutely precise
you can use wildcards (because _443._tcp.www.foo.com IN TLSA 
will resolve to _443._tcp.www.bar.com IN TLSA), but I think
we should discourage the usage of the wildcards.

There's really no magic involved.

Try asking for these:

Example 1 (matches yours)
dig IN A nxdomain.rfc1925.org
dig IN TYPE65468 _443._tcp.nxdomain.rfc1925.org

Example 2 (matches yours)
dig IN A no-cname.rfc1925.org
dig IN TYPE65468 _443._tcp.no-cname.rfc1925.org
# TLSA at dest
dig IN TYPE65468 _443._tcp.www.sury.org.

Example 3 (matches yours)
dig IN A no-dest-tlsa.rfc1925.org
dig IN TYPE65468 _443._tcp.no-dest-tlsa.rfc1925.org
# no TLSA at dest
dig IN TYPE65468 _443._tcp.www2.rfc1925.org

Example 4 (both CNAMEs)
dig IN A cname.rfc1925.org
dig IN TYPE65468 _443._tcp.cname.rfc1925.org

Example 5 (no CNAMEs at all, but still sawme IP)
dig IN A www.rfc1925.org
dig IN TYPE65468 _443._tcp.www.rfc1925.org
# Compare results to Example 2

Example 6 (chained CNAMEs works too)
dig IN A chain.rfc1925.org
dig IN TYPE65468 _443._tcp.chain.rfc1925.org

(Kind of) Example #7 (wildcards)
dig IN A blah.wildcard.rfc1925.org
dig IN TYPE65468 _443._tcp.blah.wildcard.rfc1925.org
# But really this is ugly and should not be recommended
# If you want TLSA don't use wildcards

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: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Aug 2011 07:40:43 -0400

> are different from DANE perspective.

So you have made up your mind and we can't change it?

I place an objection that the WG does not have my consensus on this point.

I suggest you amend the PROTO writeup of all documents necessary to make it
clear that there is an objection including the Use Cases document if you
intend to use that to pre-empt discussion on this point.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 14:24:38 -0400

> So you have made up your mind and we can't change it?

The _DNS_ made up the mind in this case.  CNAME redirects _that name_
and _nothing else_.  It does not redirect names beneath it.  And you
can't have a CNAME at the apex.

The TLSA record is a name beneath the CNAME.  If you want to redirect,
you need to redirect it, too.

Why is that hard?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 19:27:33 -0000

>you need to redirect it, too.

It's the application view vs. the DNS view.

>From a DNS view, you're right, you add another CNAME.

>From an application view, if you've been using CNAMEs to map one URL
to another, it'll mysteriously stop working if the target URL starts
using DANE.  One response is "tough noogies", but if that's it, we
need to at least document it as a security issue.

R's,
John

---

From: Martin Rex <[email-masked]>
Date: Tue, 2 Aug 2011 21:53:33 +0200 (MEST)

> can't have a CNAME at the apex.

the current browser behaviour (for TLS Server certs from TLS X.509 PKI) 

given the URL  https://web.example.com/some/path  would be:

  -  connect()s to web.example.com:443
  -  send TLS extension SNI with value "web.example.com"
  -  uses reference identifier "web.example.com"
  -  searches for matches for "web.example.com" in DNS-ID and CN-ID

and that behaviour is independent of whether DNS contains

   a)   web.example.com   A       10.1.1.2

or b)   web.example.com   CNAME   foo.example.org
        foo.example.org   A       10.7.2.3

except that the connect() for (a) is to 10.1.1.2:443
and for (b) is to 10.7.2.3:443

The logical DNS TLSA lookup is for "_443._tcp.web.example.org"

> you need to redirect it, too.

The straightforward case would be

   a)   _443._tcp.web.example.com   TLSA   "web.example.com stuff"

but you're saying it could be

   b)   _443._tcp.web.example.com   CNAME  _443._tcp.foo.example.org
        _443._tcp.foo.example.org   TLSA   "foo.example.org stuff"

That means that one needs to check the DNSSEC signatures not
only on the TLSA record, but also on the CNAME record leading to it.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 16:09:15 -0400

> need to at least document it as a security issue.

Yes, I am perfectly happy to see such a note.  In my view, the current
draft's text says exactly enough on this subject, but if someone wants
it to say more they should propose text.

What I have been objecting to in Phill's argument is that he seems to
be suggesting there's something special here, and there isn't.
CNAMEs, DNAMEs, and wildcards are sharp, pointy objects in the DNS,
and just because people use them without thinking all the time doesn't
make them any safer.  They've always caused people trouble in this way.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 22:51:39 +0200

> need to at least document it as a security issue.

Fine with me.  I already said before that we may put all possible cases
with verbose examples to DANE operations document (like "if you want this,
you need to do this" and "if you want that, do that").  It is also fine
with me to put a section into the security considerations of dane protocol.

Is something like moving this text from appendix A:

   The TLSA RR is not special in the DNS; it acts exactly like any other
   RRtype where the queried name has one or more labels prefixed to the
   base name, such as the SRV RRtype [RFC2782].  This sometimes causes
   confusion for some developers when using DNS aliasing and wildcards.

to security considerations and adding something like this:

   That also means that if the queried name is a CNAME record the DANE
   aware application will not automatically use TLSA RR at the canonical
   name, the target of CNAME, but the zone operator will have to create
   appropriate resource records for the queried name.  That could be
   TLSA record at prefixed queried name or CNAME for prefixed queried
   name which leads to a TLSA record.

(Somebody please propose better text not in pidgin :).

O.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 14:02:54 -0700

> (Somebody please propose better text not in pidgin :).

Why is that a security consideration?

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Aug 2011 17:54:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Schlyter
> Sent: Monday, August 01, 2011 10:46 PM
> To: John Levine
> Cc: [email-masked]
> Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards
> 
> An application using DANE would not look up www.foo.com, as this name
> does not carry any TLSA records. The application would look up
> _443._tcp.www.foo.com, which returns nothing.

I thought that at one point the discussion was to allow www.foo.com to carry
TLSA records as they would be considered to be common to all services on the
system (unless otherwise overridden).

Jim

> Yes, this is valid. See my not on SNI in another thread (foo & bar may
have
> different certs at the same endpoint).
> 
> > Example 3:
> >

---

From: [email-masked]
Date: Tue, 9 Aug 2011 09:18:41 +0000

> Yes, this is valid. See my not on SNI in another thread (foo & bar may have different certs at the same endpoint).

	this seems analogous to this particular configuration...

53.0.0.127.in-addr.arpa.   in ptr  www.foo.com.
			   in ptr  www.bar.com.

	and asking "is it valid?"  (yes)  and not  "which one gets used?"  (the first one?
	the second one? or both?) and what metrics are used to discriminate.

	extending Johns example a bit...

www.foo.com CNAME www.bar.com
www.bar.com A     1.2.3.4
_443._tcp.www.foo.com TLSA "foo stuff"
_443._tcp.www.bar.com TLSA "bar stuff"
_443._tcp.www.bbss.com TLSA "bbss stuff"
_443._tcp.www.example.com TLSA "example stuff"
_443._tcp.www.AA.com TLSA "UAL stuff"

	valid?  sure.   useful?  

/bill

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 9 Aug 2011 14:46:26 +0200

> 53.0.0.127.in-addr.arpa.   in ptr  www.foo.com.

Bill, are you suggesting that the TLS client should follow the PTR to fetch security goo from hosts listed in the PTR RDATA?  If so, what is the use-case?

	jakob

---

From: [email-masked]
Date: Tue, 9 Aug 2011 15:30:18 +0000

> Bill, are you suggesting that the TLS client should follow the PTR to fetch security goo from hosts listed in the PTR RDATA?  If so, what is the use-case?

	that is a possibility - however more to the point, the -first- PTR encountered is
	used, regardless of other data present in the RRset.  Would the same logic be used
	in the case of multiple TLSA RRs in an RRset?  If not, and caching occurs, can I 
	populate a cache w/ spurious TSLA RRs?

/bill

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Aug 2011 08:52:33 -0700

> 	populate a cache w/ spurious TSLA RRs?

When you say "can I populate...", do you mean "I" is the name owner or an attacker. If you meant "an attacker", the answer is "no" because the responses are protected by DNSSEC. If you meant "the name owner", then sure they can. For example, when you are changing from one certificate to another, you would probably want to put both TLSA records in the DNS.

--Paul Hoffman

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 9 Aug 2011 18:11:23 +0200

> 	populate a cache w/ spurious TSLA RRs?

There is nothing wrong with multiple TLSA records - the current protocol specification says that the certificate association is valid as long as any of the listed associations (TLSA RRs) matches (and, of course, validates).

	jakob

---

From: [email-masked]
Date: Tue, 9 Aug 2011 16:31:20 +0000

> There is nothing wrong with multiple TLSA records - the current protocol specification says that the certificate association is valid as long as any of the listed associations (TLSA RRs) matches (a…

	ok...  then plz clarify for me - since it seems to be an emergent property
	from other threads - can TLSA RRs be queried/matched as individual RRs?  
	e.g. can I "walk" a TLSA "chain" independently of normal namespace queries?
	(the following CNAMES, chaining, et.al.)  which, if true, seems to fly in the 
	face of "atomic" RRsets.

/bill

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Aug 2011 09:41:43 -0700

> 	from other threads - can TLSA RRs be queried/matched as individual RRs?  

Absolutely. That is how they are specified in the current draft.

> 	e.g. can I "walk" a TLSA "chain" independently of normal namespace queries?

There is no "TLSA 'chain'". The TLSA record does not refer to other DNS records.

> 	(the following CNAMES, chaining, et.al.)  which, if true, seems to fly in the 

The "other threads" are proposing a change to the normal DNS rules, specifically for for the TLSA RR; the current document uses the normal DNS rules. Does that clarify?

--Paul Hoffman

---

From: [email-masked]
Date: Tue, 9 Aug 2011 17:03:06 +0000

> The "other threads" are proposing a change to the normal DNS rules, specifically for for the TLSA RR; the current document uses the normal DNS rules. Does that clarify?

	Goodie!  a valuable attack vector is re-opened!  
	(normal DNS rules in a DNSSEC enabled environment are pretty clear
	 that while you can query individual RRs, you get the entire RRset back)

	if I can push/pull TLSA RRs into/outof cache -independently- of the 
	associated RRset, then we have the cache manipulation problem all over
	again - in spades.

/bill

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 9 Aug 2011 19:19:06 +0200

> 	associated RRset, then we have the cache manipulation problem all over

Yes, if you can compromise the cache - and bypass DNSSEC validation - you are toast. Please describe how this is a new problem.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Aug 2011 13:36:15 -0400

Again, stop misrepresenting the proposal.

No changes to the normal DNS rules

We are not going to arrive at consensus if people misrepresent proposals.

On Tue, Aug 9, 2011 at 12:41 PM, Paul Hoffman <[email-masked]> wrote:

> >>>> Bill, are you suggesting that the TLS client should follow the PTR to
> fetch security goo from hosts listed in the PTR RDATA?  If so, what is the
> use-case?
> >>>>
> >>>
> >> There is nothing wrong with multiple TLSA records - the current protocol
> specification says that the certificate association is valid as long as any
> of the listed associations (TLSA RRs) matches (and, of course, validates).
> >
> The "other threads" are proposing a change to the normal DNS rules,
> specifically for for the TLSA RR; the current document uses the normal DNS
> rules. Does that clarify?
>
> --Paul Hoffman
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Aug 2011 13:46:57 -0400 (EDT)

> Yes, if you can compromise the cache - and bypass DNSSEC validation - you are toast. Please describe how this is a new problem.

I think there is some confusion here,

The RRSIG is over the RRset, not over the individual TLSA RRs.  So you cannot pull
one TLSA record from the RRset of TLSA records at _443._tcp.example.com. and have
it validate.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Aug 2011 11:24:12 -0700

> 	 that while you can query individual RRs, you get the entire RRset back)

It looks like you misinterpreted my answer. You asked "can TLSA RRs be queried/matched as individual RRs?" and I replied that they could be matched as individual RRs. There is, of course, no way to query them as individual RRs. If that is unclear in the spec, by all means point out where so that Jakob and I can clarify there.

> 	associated RRset, then we have the cache manipulation problem all over

But we don't, fortunately. 

--Paul Hoffman

---

From: [email-masked]
Date: Wed, 10 Aug 2011 10:52:39 +0000

> Yes, if you can compromise the cache - and bypass DNSSEC validation - you are toast. Please describe how this is a new problem.

	ah...  so the TLSA rr -is/remains- bound to the RRset.  happier camper.
	btw,  what happens when a zone w/ TLSA rr's  goes insecure, e.g. the zone
	admin reverts to unsigned state?  

/bill

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 10 Aug 2011 12:54:57 +0200

> 	admin reverts to unsigned state?  

TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored (as TLSA requires data to be secure).

	jakob

---

From: [email-masked]
Date: Wed, 10 Aug 2011 10:58:26 +0000

> TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored (as TLSA requires data to be secure).

	returned and ignored  or not returned at all?

/bill

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 10 Aug 2011 13:00:12 +0200

> 	returned and ignored  or not returned at all?

The DNS (stub) resolver library will of course find them, it is up to the application to ignore them as they are not secure.

	jakob

---

From: [email-masked]
Date: Wed, 10 Aug 2011 11:02:41 +0000

> The DNS (stub) resolver library will of course find them, it is up to the application to ignore them as they are not secure.

	ok.  TLSA spec advice to API/Apps developers v. actual protocol spec.

/bill

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Aug 2011 09:55:45 -0400 (EDT)

> TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored (as TLSA requires data to be secure).

Is that in the protocol document? There has been a lot of discussion about whether or
not DNSSEC for dane records is mandatory with some rather odd theoretical use cases
specified that could benefit without it.

In any way, I think any sane TLS client supporting TLSA will not trust TLSA/HASTLS records
without proper dnssec validation.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 10 Aug 2011 16:29:02 +0200

> specified that could benefit without it.

The current draft says:

  "In order to use one or more TLS certificate associations described in
   this document obtained from the DNS, an application MUST assure that
   the certificates were obtained using DNS protected by DNSSEC."

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Aug 2011 19:06:44 +0100

All the document can say is that without DNSSEC there is limited reason to
trust a TLSA record.

Clients currently accept completely unauthenticated keys for certain
transactions, unauthenticated TLSA are going to be better than self-signed
certs.

So what it comes down to is what, if anything the user is told. And if the
User Experience is out of scope there is nowt the spec can say on that.

I doubt it really matters what the draft says on this particular point.

On Wed, Aug 10, 2011 at 2:55 PM, Paul Wouters <[email-masked]> wrote:

>  TLSA DNSSEC validation results in INSECURE and the TLSA records are
>> ignored (as TLSA requires data to be secure).
>>
>
> ______________________________**_________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dane<https://www.ietf.org/mailman/listinfo/dane>
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Aug 2011 14:31:33 -0400 (EDT)

On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote:

> unauthenticated keys for certain transactions, unauthenticated TLSA are going to be better
> than self-signed certs. 

I don't see that. Either can be MITMs and should be treated equally bad.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Aug 2011 20:00:34 +0100

It depends on what you think the reaction is going to be to lack of crypto

1) Abort the communication
2) Communicate in plaintext

All empirical evidence points to the second being what real people do.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Aug 2011 15:26:04 -0400 (EDT)

> 2) Communicate in plaintext

How is it different if the lack of crypto comes from  unauthenticated
TLSA or selfsigned certs?  Even you lumped them together in the above
explanation. So I still don't understand how unauthenticated TLSA are
better then selfsigned certs. the only far fetched reason i can come
up with is that dns is "out of band", but really, when being MITMed for
https, they can MITM DNS too.

Paul