Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 4 Oct 2010 23:32:19 -0700

On Oct 4, 2010, at 5:46 PM, Martin Rex wrote:

>> DNSSEC provides a "secure" association FROM the name TO the IP address.
>> But the DNS domain owner tends not to be the host owner so this asserted
>> association may not reflect the intent of the host owner.
>> Also, DNSSEC doesn't protect from IP hijacking (re-routing).
> 
> Incorrect characterisation.  DNSSEC provides only for secure distribution
> of DNS records.  Whether the distributed DNS records are accurate or
> trustworthy is a completely distinct issue.

I think secure distribution of DNS records implies secure distribution of name to IP associations.  

Whether those records are <whatever/> depends on the practices of the domain administrator.  Is a 3rd party CA is more or less (likely to be) trustworthy than the relevant domain administrator?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Oct 2010 04:00:55 -0400 (EDT)

>> Incorrect characterisation.  DNSSEC provides only for secure
>> distribution of DNS records.  Whether the distributed DNS records
>> are accurate or trustworthy is a completely distinct issue.

Yes, it does, name-to-IP associations being one of the major things the
DNS is used for.

But the original statement was that DNSSEC provides "secure"
association from name to IP.  This is a stronger property than
providing secure distribution of name-to-IP mapping information; it
also implies that the creation of that information and its injection
into the distribution mechanisms are "secure" (whatever that means - I
note that none of these say what they are talking about being secure
against; perhaps I'm just missing context).

> Is a 3rd party CA is more or less (likely to be) trustworthy than the
> relevant domain administrator?

There are (at least moderately) common scenarios in which it's the one
way around; there are other similarly common scenarios in which it's
the other - at least for most types of trust; again, this doesn't give
much hint of the threat model of interest.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Oct 2010 02:46:11 +0200 (MEST)

Michael StJohns wrote:
> 
> DNSSEC seems to be picking on PKIX and vice versa
> - maybe the right answer is both?

In theory, PKIX could provide real value.

In practice, the PKIX abuse commonly described as "TLS PKI"
that performs a non-popup server endpoint identification with the help
of target DNS hostnames has infinitesimal close to zero value over DNSSEC.

Conceptually, limiting the certificates that can be used to provide
servers on specific DNS hostnames to certificates explicitly listed
by the DNS admin would significantly reduce the huge attack surface
of the existing "TLS PKI" with >100 independent pre-configured
trust-anchors in most TLS client software.

> 
> PKIX provides a "secure" association TO/FROM "a" name to a public key.

This "secure" association is limited to specific "vetted" attributes
(which may or may not be described in a legalese Certificate Practice
 Statement (CPS)), with one notable and serious exception:
Any occurrence of a DNS hostname in a PKIX cert is based entirely
and completely on the DNS delegation records, and all of the popular
non-prompting server endpoint identification completely ignores all
carefully reviewed cert attributes and relies _completely_ on the
DNS hostnames based on the DNS delegation records.

>
> The host owner holds the private key and can prove "ownership" of the
> related public key.  But the host owner tends not to be the domain
> owner so the asserted association may not reflect the intent of the
> DNS domain owner.

While this may be true in practice, the domain owner is a person that
is definitely entitled to get certs issued for hostnames in his domain
from most (probably all) "TLS PKI CAs" and the domain owner is also
the one that can create and is entitled to distribute arbitrary DNS
records in his DNS domain through DNS and DNSSEC protocols.

Authentication that should reliably exclude the DNS admin for a
servers DNS hostname from acquiring a "valid" server cert, will need
to completely ban the DNS hostname from the server endpoint identification.
One means to do this would be to securly authenticate the server by
his public key, also called "certificate pinning",
also mentioned here http://www.w3.org/TR/wsc-ui/#selfsignedcerts 

Selective trust and trust being affected by repeated encounter is
evolutionary heritage and intrinsic to every mammal and most human beings.
Unfortunately, some TLS-clients make it increasingly difficult to practice
such evolutionary proven approaches to server endpoint identification.

-Martin

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Oct 2010 23:17:47 +0200

People keep referring to the 100+ vendor CA jungle. It is somewhat 
impolite to point it out, but there are very few major vendors in this 
space, and these vendors have been implicated in some of the most 
publicized attacks. In some cases, hiding behind a "low-cost" brand name.

In other words, the problem with the TLS PKI is not (only) the small fish.

Thanks,
	Yaron

On 10/05/2010 02:46 AM, Martin Rex wrote:
[...]
> of the existing "TLS PKI" with>100 independent pre-configured

---

From: Doug Barton <[email-masked]>
Date: Sun, 10 Oct 2010 21:11:10 -0700

> against; perhaps I'm just missing context).

Sorry, almost nothing you wrote above is true. The only thing that 
DNSSEC has ever claimed to be able to do is provide a way for the end 
user of the DNS data to prove to herself that the data they received is 
the data that the administrator of the zone wanted them to have. The use 
of the word "security" in the name of the protocol extension was an 
incredibly unfortunate choice because it conveys all of the 
misunderstandings you listed above, and a lot more.

Doug

-- 

Breadth of IT experience, and    |   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |		-- OK Go
http://SupersetSolutions.com/