[ksk-rollover] IoT devices and KSK rollover

[Michael Casadevall]

Replies inline, cutting out most of the quoted text for length.

I want to stress the point that I *want* signed records available to the
end user but we're not at a point where the infrastructure is there to
do this.

> Nothing crypto can bootstrap itself and be 100% secure.  It is mathematically
> impossible. Complaining about that is like asking for a unicorn.  You can ask as
> much as you want but it will not happen.
> 

We can do better than RFC 5011. In the TLS world, operating systems
maintain stores with valid root certificates. As CAs rise and fall, the
root stores get updated, old software can connect to new CAs and things
just keep working.

While I won't say this process is perfect, TLS communication is
essentially an OS function with Microsoft providing SChannel and a root
store, Apple providing Secure Transit and it's root store, and most
Linux distributions shipping TLS libraries configured to use a CA bundle
file (Ubuntu has update-ca-certificates command for this purpose).

Right now, for the KSK, the only mechanism for distributing root keys is
downloading them from IANA or RFC 5011 if you're a DNS server of some type.

> Hardware reset + trust on first use works reasonably well.  That is essentially
> what lots of us do for WiFi.
> 
> The equivalent of
> 
> “dig +short dnskey . | awk ‘$1 == 257 { … }’ > tmp”
> 
> with sanity checking before moving into place.  
> 

I'll agree that this is likely better than the current situation with
RFC 5011. However, this behavior should be standardized via RFC or at
least a BCP.

That being said, if we can do better, we should.

>> Furthermore, there is no standardized API for validating DNSSEC
>> information outside of a DNS recursive resolver implementation (AD=1).
> 
> There is no standard resolver API.  Posix doesn’t have one.  getaddrinfo()
> sits above the resolver.  That said there are a number of resolver
> implementations that are available and are compliant with STD13.
> 
> res_send(), res_search(), and anything else that returns the full answer.
> 
> 	bool ad = buf[3] & 0x20;
> 
> Yes, this is working at the level of the resolver.
> 

res_* are a de facto standard; they're originally from BSD 4.3, and
exist in one form or another in every major UNIX and UNIX-like distros.
Granted, not all implementations support DO=1, but the API itself is
very wide spread. Furthermore, the DNS client library is beside the
point beyond being able to retrieve records and checking the status of AD.

That being said, we're talking more about just the capabilities of the
resolver.

>> I'm unaware of a library that I can drop into my code, does DNS for me
>> on my behalf (with or without the system stub resolver), and compares it
>> to a list of KSKs I know is valid. Even if said library *existed*, we'd
>> just extend the number of places that breaks on a KSK rollover, and due
>> to the previous paragraph, that's a *bad* thing.
>>
>> If you want that, you can install dnssec-trigger. dnssec-trigger however
>> causes additional load on both the root and intermediary servers by
>> causing additional lookups to do DNSSEC validation.
>>
>> Userland applications have no way of knowing if their DNS responses are
>> going to a trusted source, most end users are just going to accept
>> whatever their DHCP server tells them, and most recursive resolvers
>> can't be trusted.
> 
> The point of doing DNSSEC in the app is that you do not have to trust
> the resolver.  You can verify the answer yourself.
> 

By the standard you set, checking the AD bit by itself is insufficient.
I agree with you since recursive resolvers can lie as much as they want,
so we need to handle the alternative. A large part of my research
project time is categorizing recursive resolvers and building tools to
understand them.

Verifying RRSIG data requires having the root KSK beforehand or
trust-on-first-use from the root, then having a complete set of
DS/DNSKEY/RRSIG records from the root downward to the leaf node (or
RRSIG/NSEC(3) for confirming a zone is not signed), being able to parse
said records, perform the necessary crypto validation, and then verify
that everything is kosher.

Fine, I'm all for that but at a level that is entirely transparent to
the application especially because it's a lot of work.

> There are a number of DNSSEC capable libraries that can validate answers
> you get back from upstream.
> 
> This isn’t a matter of the technology not being available.  It’s a matter
> of people not using it.
> 

The problem is I need a library to validate the DNSSEC answer. That's
the wrong solution.

The correct solution is the operating system (or whatever you're using
for DNS and sockets) should be doing this transparently when I tickle
gethostbyname() and friends. Fixing an application at a time to validate
DNSSEC is like subtracting one from infinity; we're not going to get
anywhere like that (this is a point I've been trying to hammer in UASG
in regards to "oh, just use this third party IDN library and fix every
place your app uses domain names").

The way we fix this is we publish a BCP on how we should be doing secure
DNS queries in 2019: do the query, and either request all the records we
need, or use a mechanism like RFC 7901 CHAIN to get them in a single go.
With broken resolvers that can't handle DNSSEC, skip them and recuse
from the root as a last resort.

Great, now that we have a BCP, we go to glibc, and write a patch that
implements DNSSEC validation at the resolver level with a new flag to
opt out by setting DO=0 (or CD=1 depending on your needs) and justify
the change by pointing at that BCP. Boom, you've fixed it for all Linux
distros.

We go to Mozilla and add support to NSS/NSPR, boom, all Mozilla
applications now do it correctly out of the box. Repeat for any other
DNS resolver implementations. Apply necessary pressure to Apple and
Microsoft to change their respective operating systems.

Add DoT/DoH on top and we have a nice shiny secure DNS ecosystem. KSK
updates can happen as part of standard security updates and all apps get
fixed at once. Everyone wins.

I'm not saying this would be easy or even as straightforward as I'm
making it sound (I'm not naive, this would be an uphill battle all the
way), but depending on application makers to fix their apps one by one
to add DNSSEC validation is never going to work.

It's 2019 and we've still got lots of things that go boom on pure IPv6
networks and that's been going almost 25 years now and that has a *lot*
more incentive for developers than checking DNSSEC status in the
application layer, especially since most developers aren't even aware
DNSSEC validation affects them at all.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2468 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190702/c3fea76e/pEpkey-0001.asc>