Subject: [dnsext] Thinking about a DNSSEC api...

From: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 08:19:28 -0700

On the DNSSEC adoption front, my views have been pretty clear.

	One of the items I believe is necessary is a better API for  
applications, since thats where I believe the true value of DNSSEC lies.

	So here are my thoughts.  Comments?  Suggestions?

rootoftrust management:

	An individual application can add/change/remove the roots of trust  
that the DNSSEC API will use.  Such changes ONLY apply to the  
individual application.  Roots of trust are specified by key and root  
domain.

	There needs to be a reasonable default root of trust here.

gethostbyname() -> IP Address:

	This, from the application viewpoint, operates unchanged with DNSSEC  
enabled on the end host.

	There are a few differences on the back-end however:

	1)  The stub resolver/API will ONLY cache data which it can validate  
the DNSSEC signatures.

	2)  On ANY DNSSEC failure, INCLUDING an absence of DNSSEC  
information, the local stub resolver generates an independent  
iterative request, using only its OWN (DNSSEC-validated) cache, and  
bypassing the recursive resolver completely for any data it can't  
validate the DNSSEC signature for.

	For such requests, it will first contact the recursive resolver going  
up the heirarchy, taking the first result that it CAN validate the  
signature on.  But otherwise, it will conduct its own independent  
iterative query, bypassing the recursive resolver completely.

	Why this policy?

	Because it actually offers substantial protection for existing  
applications using gethostbyname():

a)	The applications are protected against all out-of-path attacks on  
any cache, regardless of the state of the caches and their  
implementation.

b)	If the API/stub resolver does proper port randomization and 0x20,  
the applications are protected against all out-of-path attacks on the  
transaction with very high confidence.

c)	The applications are protected against all malicious behavior from  
the recursive resolver, the one significant in-path attacker for DNS  
thats not in-path for the final application.

	Simply put, effectively all applications using gethostbyname() either  
don't rely on the name (because its end-to-end crypto and changes to  
the name->addr mapping are no different than an in-path adversary) or  
are trivially vulnerable to in-path adversaries.  Thus the latter gain  
protection against the one in-path for DNS adversary thats not in-path  
for the final application, as well as complete protection against out- 
of-path adversaries.

	The (dis)advantage is anyone NOT using DNSSEC on their authority side  
is going to get slammed.

	If a major OS changes its API to use this scheme, it should use a  
random "cooking the frog" deployment:  For the default user (no  
explicit selection), there is initially a 0% chance, rising to 100%  
chance over a one year period, to give authorities and recursive  
resolvers time to adapt.

gethostbynamesecure(name) -> (IP ADDR, error status)

	This ONLY returns an IP address if the DNSSEC signature can be  
completely validated, OTHERWISE it returns the reason for the error  
(unknown root of trust, expired key (and where in the chain), no  
DNSSEC information, etc).

	(almost) useless, but included for completeness.

getkeybynamesecure(host, service) -> (block of opaque bytes, error  
status)

	This does a lookup for the NULL RDATA information for service.host,  
verifying the DNSSEC signature and returning the bytes or the error  
status.

	This provides a generic mechanism for storing cryptographically- 
verified, service specific material in DNS.  Thus applications can use  
this as an application-defined convention to look up various important  
features.

	EG, tls.www.example.com -> the SHA256-sum of the TLS certificate for  
the server
	ssh.login.example.com -> the SSH fingerprint.
	ipsec.example.com -> An IPSec public key for ALL IP communication

	This has a huge advantage over schemes like, say RFC 4255 in that it  
does not require changes to the DNS protocol or authority code to add  
applications/extend features, but it allows ANY application to have a  
cryptographically verified name->key mapping that is application  
specific.

	Additionally, one could easily have the authority forward the final  
request for service.host to the host itself, which means the  
authorities themselves don't need to care, they just need to make sure  
that they know the host's key as a step in the chain.

	This is, I believe, the key building block for DNSSEC:  It gives  
something that secure applications can actually use, but at the same  
time, does not impose application semantics on the DNS system beyond a  
simple mapping, nor does it require the authorities to understand all  
the services.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 24 Apr 2009 09:29:00 +0200

On Thu, Apr 23, 2009 at 08:19:28AM -0700,
 Nicholas Weaver <[email-masked]> wrote 

> gethostbyname() -> IP Address:

Why the IPv4-only antediluvian gethostbyname and not RFC 3493?