IoT devices and KSK rollover
ICANN has a document at: https://www.icann.org/en/system/files/files/sac-105-en.pdf about IoT and DNS, opportunities and risks. (I liked that it had both). One point is:
5.1 Developing a DNS security and transparency library for IoT devices
The first challenge is developing and maintaining an open source DNS security library that makes functions like DNSSEC validation, DANE, and DoH/DoT available on IoT devices. The library would need to include transparent support for routine root KSK rollovers, such as automatically changing keys and notifying the DNS of which KSK an IoT device is currently using [45]. This will likely be more challenging than with traditional resolvers, partly because it may not be possible to remotely update IoT devices, and many IoT devices lack the non-volatile storage necessary to store keying material.
While the points in the last sentence are certainly true, they aren't particularly relevant. Keys are not that big compared to the code to use them. More and more often, IoT devices are updateable, the issue is that they can't really be updated if they are turned off, in a warehouse. Despite what other parts of the document suggest, I don't think that DoH is a useful thing for IoT. I think actually the opposite, but this section seems to suggest that someone, ICANN?, will be considering funding or doing some software development to make a useful validating stub resolver work in an constrained device. (OpenWRT is not really that code constrained, RIOT-OS is). I am bringing this up here, because I think that there is an opportunity here to *define* (to lead) on how to do IoT with DNSSEC and tolerating long-term offline storage. That is, if I understood this SSAC ICANN document's point. There are a multitude of ways to do this, and we have discussed this, but let me repeat the two major paths: 1) a way to upgrade from the KSK known at the time of manufacturer to today's key. -or- 2) a way to reliably (without being easily spoofed), turning off DNSSEC validation long enough to search out, and get a firmware update that has the today's keys. ---- The document goes on to talk about training, and while this part is not particularly KSK relevant, I wrote another email about this document about IoT and DNS and MUD, I think that it's worth repeating here.
* Training IoT and DNS professionals (Section 5.2) to help DNS players such as registrars and registrants understand the implications of providing services for domain names that act as a backend for IoT devices rather than as a means for making content available to humans (Section 3.3), and to help IoT device manufacturers understand how to use the DNS and how to configure resolvers (Sections 4.1 and 4.3).
I think that there is a missing element here, which is talking about DNS at IoT conferences, about the libraries one can use, but most importantly, about how to do DNS in a way that makes MUD easier to do. There is also a need to reach out to the CDN community, and deal with the question of names to IP mapping, and how we make sure that the name provides the service requested, and only that service. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Jun 12, 2019, at 2:38 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
I don't think that DoH is a useful thing for IoT.
I suspect there are a couple of issues. One is that DNS (RFC 1034 and so on) sends a packet and gets a response packet. Doing the same thing with HTTPS (HTTP 2.0, presumably, TLS, and TCP) requires session setup at two layers plus the overhead of parsing HTTP to accomplish the same thing. To my way of thinking, IPsec requires a single additional header plus whatever state is required to ensure that one is talk with the right party and perhaps encrypting that. I don't see what the imposition of several layers of software buys - not just for IOT, but for anything. In addition, DOH takes DNS service out of the domain that is managing the IOT cloud, which may not be what the owner of the device intends. There is a business issue in that. An analogous one is national: Turkey imposed a regulation saying certain names should not be accessible in Turkey, Turk Telecom imposed a DNS filter, people went to 8.8.8.8 to bypass the filter, and Turk Telecom wound up hijacking that particular route. If a company for its own reasons wants its users to use its own resolver, DOH gives a random device vendor the means to violate that security provision. I tend to think that if someone wants to implement DOH, that's fine, but corporate IT needs to ability to impose its own policy there. It needs to be possible to force the use of the DNS protocol rather than HTTPS, to specify the address and key of a chosen DOH server, etc. I can write that up in an I-D if it helps. -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu
Fred Baker <fredbaker.ietf@gmail.com> wrote: > I tend to think that if someone wants to implement DOH, that's fine, > but corporate IT needs to ability to impose its own policy there. It > needs to be possible to force the use of the DNS protocol rather than > HTTPS, to specify the address and key of a chosen DOH server, etc. https://datatracker.ietf.org/doc/draft-reddy-dprive-bootstrap-dns-server/ tries to do that for almost all the reasons you mention. Please help. (Tiru and Dan are the brains here; I'm just the peanut gallery) A situation with DoH is that you need a secure path to the DoH anchors. While CAB limits you to 2yr end certificates, Commerial root CAs seem to all have 20yr lifetimes, and this seems pretty good. But, the device has to do certificate path validation. Do you need to have them all though? Is this a feature or a bug, I haven't decided yet. But, if you already have TLS code in the device, then maybe it's cheaper to do this instead of DNSSEC. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr@sandelman.ca> wrote:
But, if you already have TLS code in the device, then maybe it's cheaper to do this instead of DNSSEC.
That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data). You know that the data came from IANA and has not been screwed with in the process through DNSSEC. You know that the guys that handed it to you is your DOH server (and, potentially, the fact that he handed it to you) by TLS. If you only depend on TLS, the content might have changed dramatically. That, BTW, is the argument for RPKI as opposed to TLS or other hash/signature/whatever in BGP. I can tell you that the Root Server System delivers the IANA database, speaking as a root server operator and the co-chair of that committee in ICANN. If I can say this without appearing to cast aspersions, I don't know that for the DOH operators as a class. For example, and again I don't intend to cast aspersions, the YETI project (RFC 8483) downloads the root zone and then re-signs it. Apart from direct comparison, I'm not sure I have a way to know that an alternate root delivers the same data - all of the RRs, only the RRs, and each individually unchanged - apart from the IANA signature. A DOH service is essentially the same - I can trust it if and only if I'm implementing DNSSEC *and* the record I receive, by whatever channel, is signed by the Root Zone Maintainer. -------------------------------------------------------------------------------- The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
On Jun 13, 2019, at 11:54, Fred Baker <fredbaker.ietf@gmail.com> wrote:
On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr@sandelman.ca> wrote: But, if you already have TLS code in the device, then maybe it's cheaper to do this instead of DNSSEC.
That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data).
I keep saying this too and correct people every time DoH or DoT is suggested as replacement for DNSSEC. Browser vendors and DNS firewall vendors aren’t helping by building infrastructure that breaks DNSSEC by design. It’s an attack in the network. Paul
Very belated reply here, but we need to remember that DNSSEC information is not sent to the end-client nodes (stub resolvers); the recursive resolver is supposed to check DNSSEC information and then confirm authentication via a bit in the DNS options flag. This also means that recursive resolvers can lie about DNSSEC or simply choose not to validate (or the client can request no DNSSEC with the CD bit) As such, a KSK rollover should not directly affect stub resolvers as long as their resolver resolver setup has up to date root KSK information. If we're dealing with a device acting as a router running a recursive resolver, obviously the above goes out the window. As for DoT/DoH, none of the above changes as there are no wire protocol changes to DNS in either of these use cases, and the cost of implementation is stupidly high. First off, it's impossible to deploy DoT/DoH in an internal network that uses RFC1918 address space (aka 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue certificates for this address space; private enterprise CAs could, but then you need a mechanism to upload the root certificate to the IoT device. Device manufactors also need to update their devices to update their root store from time to time. It should also be noted that the current Mozilla NSS root store is approximately 250 KiB in size uncompressed. For some extremely constrained IoT devices, that can be far too large. An ATmega328 (the same chip in the Andrio Uno) only has a total of 32 kilobytes of space storage space. In contact, the WolfSSL library can squeeze into ~20 kib of flash space (https://www.wolfssl.com/products/wolfssl/) Embedded TLS is common enough in practice (since services like Amazon IoT require it), but often implement the bare minimium required with a few root stores, and likely don't implement revocation checking (CRL or OCSP) correctly or at all (speaking from experience from working on these devices). There are major issues with DoH/DoT in general, but a lot of devices in general are going to simply incapable of supporting it because the cost of full TLS support + full set of CA root certificates is simply too high in terms of flash storage. Michael On 6/13/19 12:14 PM, Paul Wouters wrote:
On Jun 13, 2019, at 11:54, Fred Baker <fredbaker.ietf@gmail.com> wrote:
On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr@sandelman.ca> wrote: But, if you already have TLS code in the device, then maybe it's cheaper to do this instead of DNSSEC.
That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data).
I keep saying this too and correct people every time DoH or DoT is suggested as replacement for DNSSEC.
Browser vendors and DNS firewall vendors aren’t helping by building infrastructure that breaks DNSSEC by design. It’s an attack in the network.
Paul _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On 2 Jul 2019, at 12:57 am, Michael Casadevall <michael@casadevall.pro> wrote:
Very belated reply here, but we need to remember that DNSSEC information is not sent to the end-client nodes (stub resolvers); the recursive resolver is supposed to check DNSSEC information and then confirm authentication via a bit in the DNS options flag. This also means that recursive resolvers can lie about DNSSEC or simply choose not to validate (or the client can request no DNSSEC with the CD bit)
What a load of hogwash. DNSSEC is designed and expected to be performed by *every* entity in the resolution chain. The AD bit is only supposed to be accepted if there is a secure path between the recursive resolver and the application. 99.999999999% of the time this is not the case unless you are talking to 127.0.0.1 or ::1. There are applications that perform DNSSEC through stub resolvers.
As such, a KSK rollover should not directly affect stub resolvers as long as their resolver resolver setup has up to date root KSK information. If we're dealing with a device acting as a router running a recursive resolver, obviously the above goes out the window.
This is short sighted thinking. One should design for ubiquitous DNSSEC regardless of whether it is achieved or not. This lets those that want DNSSEC all the way to the application have it.
As for DoT/DoH, none of the above changes as there are no wire protocol changes to DNS in either of these use cases, and the cost of implementation is stupidly high. First off, it's impossible to deploy DoT/DoH in an internal network that uses RFC1918 address space (aka 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue certificates for this address space; private enterprise CAs could, but then you need a mechanism to upload the root certificate to the IoT device. Device manufactors also need to update their devices to update their root store from time to time.
It should also be noted that the current Mozilla NSS root store is approximately 250 KiB in size uncompressed. For some extremely constrained IoT devices, that can be far too large. An ATmega328 (the same chip in the Andrio Uno) only has a total of 32 kilobytes of space storage space. In contact, the WolfSSL library can squeeze into ~20 kib of flash space (https://www.wolfssl.com/products/wolfssl/)
Embedded TLS is common enough in practice (since services like Amazon IoT require it), but often implement the bare minimium required with a few root stores, and likely don't implement revocation checking (CRL or OCSP) correctly or at all (speaking from experience from working on these devices).
There are major issues with DoH/DoT in general, but a lot of devices in general are going to simply incapable of supporting it because the cost of full TLS support + full set of CA root certificates is simply too high in terms of flash storage. Michael
On 6/13/19 12:14 PM, Paul Wouters wrote:
On Jun 13, 2019, at 11:54, Fred Baker <fredbaker.ietf@gmail.com> wrote:
On Jun 12, 2019, at 6:07 PM, Michael Richardson <mcr@sandelman.ca> wrote: But, if you already have TLS code in the device, then maybe it's cheaper to do this instead of DNSSEC.
That's apples and orangutans. TLS secures the channel (chain of custody), DNSSEC secures the data regardless of the channel (correctness of the data).
I keep saying this too and correct people every time DoH or DoT is suggested as replacement for DNSSEC.
Browser vendors and DNS firewall vendors aren’t helping by building infrastructure that breaks DNSSEC by design. It’s an attack in the network.
Paul _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
<pEpkey.asc><pEpkey.asc>_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Replies inline. Apologies but this is wordy, but from where I'm sitting, userland applications can't do anything to prove DNSSEC is both correct, secure and available. If I can be proven wrong, I'll gladly admit so. On 7/1/19 7:10 PM, Mark Andrews wrote:
On 2 Jul 2019, at 12:57 am, Michael Casadevall <michael@casadevall.pro> wrote:
What a load of hogwash. DNSSEC is designed and expected to be performed by *every* entity in the resolution chain. The AD bit is only supposed to be accepted if there is a secure path between the recursive resolver and the application. 99.999999999% of the time this is not the case unless you are talking to 127.0.0.1 or ::1.
There are applications that perform DNSSEC through stub resolvers.
The world you described is the world I'd like to live in (DNSSEC validated through the stub), but not the world we live in. I'd be happy to be proven wrong but here's how I see the world. Two examples, the Windows operating system's stub resolver, and Postfix's DANE support to show how bad of a world this really is. Let's look at Postfix first: Postfix support DANE validation for STARTTLS records. DANE requires a zone be signed via DNSSEC. The code responsible for that is here: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dane.c#... or more importantly, this line: ret = dns_lookup(tlsa_fqdn, T_TLSA, RES_USE_DNSSEC, &rrs, 0, why); dns_lookup is a macro defined to dns_lookup_x (https://github.com/vdukhovni/postfix/blob/master/postfix/src/dns/dns.h#L229). This leads to dns_res_query(), and then finally to the glibc. res_query's manpage (http://manpages.ubuntu.com/manpages/bionic/man3/res_query.3.html) has the following to say on the subject: int res_query(const char *dname, int class, int type, unsigned char *answer, int anslen); On DNSSEC, it says the following: RES_USE_DNSSEC Use DNSSEC with OK bit in OPT record. This option implies RES_USE_EDNS0. The long and short version is that Postfix's DANE support requires the DNS resolver pointed to in /etc/resolv.conf 1. support DNSSEC 2. Properly implement KSK-2017 3. Not lie about the status of the AD bit. As of writing, here's what my /etc/resolv.conf says while connected over Wifi at my mom's apartment: mcasadevall@dawntreader:~/src/postfix-3.3.0$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 10.0.0.1 10.0.0.1 is a *very* cheap NetGear router. A look at the router's settings page suggests it's just a forwarding resolver pointed at Verzion FIOS's DNS servers which it got from upstream DHCP. --- The situation on Windows is even worse. Right off the bat, It does not ship with a DNS server out of the box listening on ::1 so any and all behavior exists solely in the stub resolver (which is part of Winsock), and Microsoft only provides a DNS server on Server editions of Windows (which is not installed by default). In almost all application code, a call for a domain name (to get an A/AAAA) record is either going to be done by getnameinfo() or DnsQuery[Ex](). Both of these functions are essentially standard for tutorials for doing socket programming with Winsock (esp. getnameinfo()). That DNS query is going to go to the network adapter's default DNS resolver which is usually going to be set by DHCP by the router. The router may set itself as the server (where it may just be a forwarder or a recursive resolver), point at the ISP, or possibly point at a public DNS server such as 8.8.8.8. The stub resolver will not check DNSSEC information, leaving it to the upstream server to do it's job for it (and should return BADSIG, etc. if DNSSEC is broken). I've spent the last hour looking through MSDN, and I can't find a single API that validate DNS traffic against DNSSEC directly or check DNSSEC record validity. It doesn't even appear I can reuqest DO=1 via the DnsQuery API (https://docs.microsoft.com/en-us/windows/desktop/DNS/dns-constants; see DNS Query Options). I spent the better part of an hour searching MSDN for this. The only functionality that directs the behavior of the stub I can find is the Name Resolution Policy Table (NRPT). NRPT is controlled by group policy (usually through Active Directory) and can change the behavior of the DNS stub resolver to require validation. The mechanism for changing and updating trust anchors for the stub resolver appears directly tied to Active Directory and it's DNS server; I don't have a local AD tree to test at the moment. There's no way as far as I can see to directly get the status of the AD bit on Windows (I'll be happy to be proven wrong) or load and change KSK trust anchors unless a machine is part of a domain and said trust anchors are distributed through active directory. The Windows Server documentation details how to do this.
As such, a KSK rollover should not directly affect stub resolvers as long as their resolver resolver setup has up to date root KSK information. If we're dealing with a device acting as a router running a recursive resolver, obviously the above goes out the window.
This is short sighted thinking. One should design for ubiquitous DNSSEC regardless of whether it is achieved or not. This lets those that want DNSSEC all the way to the application have it.
How? Applications can't even trust DNSSEC information (if available) with current APIs and libraries and the tech has been around for two decades. KSK-2017 was deployed in Ubuntu and Debian by doing SRUs for all the DNS servers to add it to bind.keys or it's equivalent. RFC 5011 only worked while KSK-2010 and KSK-2017 were both in the root; KSK-2017 was manually added to bind.keys so that BIND could work and bootstrap itself on new installs on older distros (i.e 16.04) that predate KSK-2017 or on systems enabling dnssec-validation now post-KSK2010's removal. We don't have a mechanism that allows for bootstrapping a new KSK unless the old one is still in the root. For software that gets clean installed when a new KSK is installed, they won't be able to bootstrap to the latest KSK. Furthermore, there is no standardized API for validating DNSSEC information outside of a DNS recursive resolver implementation (AD=1). 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. Michael
On 2 Jul 2019, at 12:50 pm, Michael Casadevall <michael@casadevall.pro> wrote:
Replies inline. Apologies but this is wordy, but from where I'm sitting, userland applications can't do anything to prove DNSSEC is both correct, secure and available. If I can be proven wrong, I'll gladly admit so.
On 7/1/19 7:10 PM, Mark Andrews wrote:
On 2 Jul 2019, at 12:57 am, Michael Casadevall <michael@casadevall.pro> wrote:
What a load of hogwash. DNSSEC is designed and expected to be performed by *every* entity in the resolution chain. The AD bit is only supposed to be accepted if there is a secure path between the recursive resolver and the application. 99.999999999% of the time this is not the case unless you are talking to 127.0.0.1 or ::1.
There are applications that perform DNSSEC through stub resolvers.
The world you described is the world I'd like to live in (DNSSEC validated through the stub), but not the world we live in. I'd be happy to be proven wrong but here's how I see the world. Two examples, the Windows operating system's stub resolver, and Postfix's DANE support to show how bad of a world this really is. Let's look at Postfix first:
Postfix support DANE validation for STARTTLS records. DANE requires a zone be signed via DNSSEC. The code responsible for that is here: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dane.c#...
or more importantly, this line:
ret = dns_lookup(tlsa_fqdn, T_TLSA, RES_USE_DNSSEC, &rrs, 0, why);
dns_lookup is a macro defined to dns_lookup_x (https://github.com/vdukhovni/postfix/blob/master/postfix/src/dns/dns.h#L229). This leads to dns_res_query(), and then finally to the glibc.
res_query's manpage (http://manpages.ubuntu.com/manpages/bionic/man3/res_query.3.html) has the following to say on the subject:
int res_query(const char *dname, int class, int type, unsigned char *answer, int anslen);
On DNSSEC, it says the following:
RES_USE_DNSSEC Use DNSSEC with OK bit in OPT record. This option implies RES_USE_EDNS0.
The long and short version is that Postfix's DANE support requires the DNS resolver pointed to in /etc/resolv.conf
1. support DNSSEC 2. Properly implement KSK-2017 3. Not lie about the status of the AD bit.
As of writing, here's what my /etc/resolv.conf says while connected over Wifi at my mom's apartment:
mcasadevall@dawntreader:~/src/postfix-3.3.0$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 10.0.0.1
10.0.0.1 is a *very* cheap NetGear router. A look at the router's settings page suggests it's just a forwarding resolver pointed at Verzion FIOS's DNS servers which it got from upstream DHCP.
---
The situation on Windows is even worse. Right off the bat, It does not ship with a DNS server out of the box listening on ::1 so any and all behavior exists solely in the stub resolver (which is part of Winsock), and Microsoft only provides a DNS server on Server editions of Windows (which is not installed by default).
In almost all application code, a call for a domain name (to get an A/AAAA) record is either going to be done by getnameinfo() or DnsQuery[Ex](). Both of these functions are essentially standard for tutorials for doing socket programming with Winsock (esp. getnameinfo()). That DNS query is going to go to the network adapter's default DNS resolver which is usually going to be set by DHCP by the router. The router may set itself as the server (where it may just be a forwarder or a recursive resolver), point at the ISP, or possibly point at a public DNS server such as 8.8.8.8.
The stub resolver will not check DNSSEC information, leaving it to the upstream server to do it's job for it (and should return BADSIG, etc. if DNSSEC is broken). I've spent the last hour looking through MSDN, and I can't find a single API that validate DNS traffic against DNSSEC directly or check DNSSEC record validity. It doesn't even appear I can reuqest DO=1 via the DnsQuery API (https://docs.microsoft.com/en-us/windows/desktop/DNS/dns-constants; see DNS Query Options). I spent the better part of an hour searching MSDN for this.
The only functionality that directs the behavior of the stub I can find is the Name Resolution Policy Table (NRPT). NRPT is controlled by group policy (usually through Active Directory) and can change the behavior of the DNS stub resolver to require validation. The mechanism for changing and updating trust anchors for the stub resolver appears directly tied to Active Directory and it's DNS server; I don't have a local AD tree to test at the moment.
There's no way as far as I can see to directly get the status of the AD bit on Windows (I'll be happy to be proven wrong) or load and change KSK trust anchors unless a machine is part of a domain and said trust anchors are distributed through active directory. The Windows Server documentation details how to do this.
As such, a KSK rollover should not directly affect stub resolvers as long as their resolver resolver setup has up to date root KSK information. If we're dealing with a device acting as a router running a recursive resolver, obviously the above goes out the window.
This is short sighted thinking. One should design for ubiquitous DNSSEC regardless of whether it is achieved or not. This lets those that want DNSSEC all the way to the application have it.
How?
Applications can't even trust DNSSEC information (if available) with current APIs and libraries and the tech has been around for two decades.
KSK-2017 was deployed in Ubuntu and Debian by doing SRUs for all the DNS servers to add it to bind.keys or it's equivalent. RFC 5011 only worked while KSK-2010 and KSK-2017 were both in the root; KSK-2017 was manually added to bind.keys so that BIND could work and bootstrap itself on new installs on older distros (i.e 16.04) that predate KSK-2017 or on systems enabling dnssec-validation now post-KSK2010's removal.
bind.keys was made a seperate file so that it was easy to update. Yes, we expected distributions to update it the same way as they update the CA bundle from time to time. Named has a copy of bind.keys compiled into it to use if bind.keys is not available.
We don't have a mechanism that allows for bootstrapping a new KSK unless the old one is still in the root. For software that gets clean installed when a new KSK is installed, they won't be able to bootstrap to the latest KSK.
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. 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.
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.
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. 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. Mark
Michael
<pEpkey.asc>
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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
On Tue, 2 Jul 2019, Michael Casadevall wrote:
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.
operating systems maintain DNSSEC root keys outside of 5011 as well, as part of their OS update mechanism. Whatever works for updating root CA's works for updating DNSSEC root keys.
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.
It's not. Debian/Ubuntu have a specific package that distributes the root keys. RHEL/CentOS/Fedora ship DNSSEC keys with the various DNS packages.
“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.
It's not better. It depends on your "sanity checking" of course, but this solution sounds more like a "better than nothing" solution. And I can see malware abusing such a mechanism if such mechanism is widely used. Just wait for a >5 year old IoT device to reboot, and you own it.
However, this behavior should be standardized via RFC or at least a BCP.
That being said, if we can do better, we should.
It would be nice to do better, but it is currently unclear how to. Various solution suggested in the past all fail if one of the Root keys is ever leaked/compromised.
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.
From what I'm seeing, the use of c-ares, libunbound and bind libraries are seeing increased use for in applications. Any libc based functions are being used less and less. (eg get_addrinfo(), gethostbyname*()
That being said, we're talking more about just the capabilities of the resolver.
A full DNS resolver has little use for POSIX. they have their own resolving code. The interesting bits are stubs and applications. Those are the ones that benefit the most from a good API supporting DNSSEC.
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.
He said "in the app", so the AD bit there just signifies the result was secure. In libunbound terms that is ub_result->secure. It denotes all the validation was done inside the app/library. Mark did not mean an AD bit over the wire.
The problem is I need a library to validate the DNSSEC answer. That's the wrong solution.
With dns-query-chains (and hopefully tls-dnssec-chain) you just need a library that validates such a chain, without any dns cache or direct querying.
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").
It really depends on the application and its trust in the OS. If you are pulling IPSECKEY or OPENPGPKEY's from DNSSEC, I would prefer the application does not depend on the system's resolver. Perhaps for pulling TLSA records, it is good enough.
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.
glibc is ejecting DNS code, not taking in new code. c-ares seems to be were this is concentrated these days (at least in my limited view)
We go to Mozilla and add support to NSS/NSPR, boom, all Mozilla applications now do it correctly out of the box.
Having been on the sidelines of two attempts to get this done, I wish you a lot of luck. I really hope you succeed, but at the moment I wouldn't focus on Mozilla. They are not helpful at the moment.
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.
DoT/DoH seems to be more used to pretend we don't need DNSSEC :(
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.
I'd settle for the low bar of "don't work against us please". Paul
Paul Wouters <paul@nohats.ca> writes:
We go to Mozilla and add support to NSS/NSPR, boom, all Mozilla applications now do it correctly out of the box.
Having been on the sidelines of two attempts to get this done, I wish you a lot of luck. I really hope you succeed, but at the moment I wouldn't focus on Mozilla. They are not helpful at the moment.
For reference, we (the dnssec-tools project) filed this bug *with a patch* 7 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=748232 They aren't interested in DNSSEC (and at public venues have stated negative opinions about it as well). Originally it was on their roadmap, but the browser industry then fell into the speed-war and page load speeds dominated all other measurements of success. Thus, extra DNS lookups was a non-starter. -- Wes Hardaker USC/ISI
participants (7)
-
Fred Baker -
Mark Andrews -
Michael Casadevall -
Michael Richardson -
Michael Richardson -
Paul Wouters -
Wes Hardaker