Subject: [dane] Cert. Usage 0/1

From: Alexander Gurvitz <[email-masked]>
Date: Tue, 23 Oct 2012 13:27:22 +0200

Hello.

http://tools.ietf.org/html/rfc6394#section-3.1 :

> Continuing to require PKIX validation also limits the degree to which
> DNS operators (as distinct from the holders of domains) can interfere
> with TLS authentication through this mechanism. As above, even if a
> DNS operator falsifies DANE records, it cannot masquerade as the
> target server unless it can also obtain a certificate for the target
> domain.

This seems like a mistake to me - DNS operator can always issue a
fraudulent usage 2/3 record,
and thus skip the CA validation.

The only advantage I can see in usage 0/1, is that it allows CA-based
certificate revocation
in case of the private key compromise.

Alexaner Gurvitz,
net-me.net

---

From: [email-masked] (Martin Rex)
Date: Tue, 23 Oct 2012 15:59:32 +0200 (CEST)

Alexander Gurvitz wrote:
> fraudulent usage 2/3 record, and thus skip the CA validation.

Nope.  The DNS operator can only indicate his intention.
The TLS client might not even look at DANE / TLSA records at all,
or the TLS client might be configure to warn for DANE TLSA 2/3 records
(although maybe with a less intimidating scary page than what
current browsers are showing for untrusted server certs today).

> certificate revocation in case of the private key compromise.

The information that is stored in DNS really is not trustworthy,
and the desired continued low cost of adding/changing DNS records
ensures that DNS records will never become trustworthy.

DNSSEC may add data integrity protection and data origin authentication
for the DNS records that it protects, but it does exactly ZERO about
the lack of trustworthyness of most data in the DNS.

If you search google via HTTPS rather than HTTP, the result list
is not going to become any more trustworthy.  It will only be harder
for attackers anywhere between google and you to modify your request
or google's response.

-Martin

PS: however, the entry-level "Domain validated" (DV) certs from public CAs
    feed on DNS data (AFAIK minus typosquatting), so it is difficult
    to conceive how DV-certs could be noticably more trustworthy
    than information provided through DANE.

---

From: Guangqing Deng <[email-masked]>
Date: Tue, 23 Oct 2012 22:38:53 +0800

2012/10/23 Alexander Gurvitz <[email-masked]>

> and thus skip the CA validation.

Remind that the section 3.1 just discusses the “CA Constraints” which
refers to usage 0 TLSA record but not usage 2/3 TLSA records, which is
discussed in other sections. So, the statement “even if a DNS operator
falsifies DANE records, it cannot masquerade as the target server unless it
can also obtain a certificate for the target domain” is correct.

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

-- 
Guangqing Deng

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Oct 2012 17:01:48 -0400 (EDT)

On Tue, 23 Oct 2012, Guangqing Deng wrote:

> This seems like a mistake to me - DNS operator can always issue a fraudulent usage 2/3 record,
> Remind that the section 3.1 just discusses the “CA Constraints” which refers to usage 0 TLSA record but not usage 2/3 TLSA records, which
> is discussed in other sections. So, the statement “even if a DNS operator falsifies DANE records, it cannot masquerade as the target
> server unless it can also obtain a certificate for the target domain” is correct.

But it can, just by updating the A/AAAA record to a server it owns.

I vague remember pointing out this exact mistake in the draft. I guess
we all kind of missed updating it in the end.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Oct 2012 10:20:44 +1100

In message <[email-masked]>, Paul Wouters w
rites:
> refers to usage 0 TLSA record but not usage 2/3 TLSA records, which
> > is discussed in other sections. So, the statement “even if a DNS 
> operator falsifies DANE records, it cannot masquerade as the target

It can masquerade as the machine hosting the server/service, not the
server/service itself.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Guangqing Deng <[email-masked]>
Date: Wed, 24 Oct 2012 09:43:24 +0800

2012/10/24 Paul Wouters <[email-masked]>

>> is discussed in other sections. So, the statement “even if a DNS operator
>> falsifies DANE records, it cannot masquerade as the target

What you pointed out is about the incorrect configuration of DNS resource
records, which may be another story. Just as previously discussed in this
mailing list, DNSSEC may add data integrity protection and data origin
authentication but definitely not the trustworthiness for the DNS resource
records that it protects. If the DNS operator is going to do something bad
(such as incorrectly configuring DNS resource records) intentionally or
unintentionally, DNSSEC cannot stop the DNS operator from doing that.

-- 
Guangqing Deng

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Oct 2012 22:06:28 -0400 (EDT)

On Wed, 24 Oct 2012, Guangqing Deng wrote:

>             usage 0 TLSA record but not usage 2/3 TLSA records, which
>             is discussed in other sections. So, the statement “even if a DNS operator falsifies
>             DANE records, it cannot masquerade as the target
> What you pointed out is about the incorrect configuration of DNS resource records, which may be another
> story. Just as previously discussed in this mailing list, DNSSEC may add data integrity protection and data
> origin authentication but definitely not the trustworthiness for the DNS resource records that it protects.
> If the DNS operator is going to do something bad (such as incorrectly configuring DNS resource records)
> intentionally or unintentionally, DNSSEC cannot stop the DNS operator from doing that.

And if DNSSEC TLSA records claim things about PKIX, that can be changed
too.

So I still don't understand your point (or Mark's)

Paul

---

From: Guangqing Deng <[email-masked]>
Date: Wed, 24 Oct 2012 10:45:50 +0800

>> records, which may be another

Definitely, DNSSEC TLSA records claiming things about PKIX can be changed
by the DNS operator. And one goal of DANE protocol is to restrict the scope
of certificate used by the TLS client to authenticate the TLS server. For
example, DNS operator can put the public key of a specific CA in the TLSA
record to tell the TLS client that just the certificate issued by that CA
is reliable. If the currently recommended CA is not reliable any more, of
course, DNS operator can modify the TLSA record and add the information of
a newly chosen CA in the TLSA record.

-- 
Guangqing Deng

---

From: John Gilmore <[email-masked]>
Date: Wed, 24 Oct 2012 00:08:25 -0700

Yes, section 3.1's statement is foolish, because it limits itself
by saying "through this mechanism" at the end of the first sentence:

Through the "CA Constraints" mechanism, a DNS operator cannot falsify
DANE records to masquerade as the target server.

However, through other readily available mechanisms, a DNS operator
can EASILY falsify DANE records to masquerade as the target server.

The statement is literally true as written, but is misleading about
the actual level of security provided in the real world by publishing
a "CA Constraint" TLSA record through an untrustworthy DNS operator.

	John