ableyjoe
commented
1 year ago Hi Guillaume,I have not consulted with my esteemed co-authors on the reply below, so please take this as just my opinion as a co-author inherited from RFC7958, and not any kind of statement by ICANN.I think your question about the recommendations for retrieving and processing trust anchors is a good one, but I also think it's a question that this document deliberately doesn't attempt to answer. This document tries to describe carefully how the trust anchors are published, as an informational measure intended to benefit consumers of this information and their downstream relying parties. The question of how the information should be used, once retrieved, and specifically how it should be used to bootstrap a new recursive resolver is a different one.Dave Knight and I tried to address this second question half a decade ago in draft-jabley-dnsop-validator-boostrap, but that document didn't gain any traction; from memory there was a lack of enthusiasm for it in the working group. Perhaps opinions have changed since then and we should try again. I think to be honest trust at first use feels good enough for pretty much everybody who does DNSSEC validation.As a parting comment, I agree with you that it's sensible to keep these two questions separate. ICANN might well have a future need to make changes to the details of how they publish trust anchors, as is happening right now with this document. The advice from the broader IETF about how to use those trust anchors (e.g. to bootstrap validators) comes from a different set of people. Clearly the two questions are related, but they are usefully different.As to the ICANN CA, to my knowledge it's not maintained, used or published even in the vague neighbourhood of the CA/Browser Forum. The original idea of that ICANN CA was that it could be signed by organisations who wanted to consume it in software that already included toolchains used to verify the authenticity of (e.g.) downloaded packages. Examples of those orgnisations were DNS software vendors, operating system vendors, etc. Such organisations' would then have a means to retrieve the trust anchor without any requirements around channel security and be able to validate its authenticity on the host that retrieved it.Since the ICANN CA was never really used by anybody that we knew of when I was at ICANN, we didn't put any great effort into the processes surrounding its management. Wasn't really my area, to be honest (I was mainly workinig on operations, not security architecture) but that was the impression I got. The main person who was enthusiastic about maintaining an ICANN CA left the organisation quite some time ago, as far as I know.JoeOn 11 Sep 2023, at 14:54, Guillaume Bailey @.***> wrote: Hi Paul, Joe & Jakob, I read the latest draft. One question I have, is what's the recommended procedure for a DNS server to bootstrap? It seems like the ICANN CA certificate could be hard-coded into the software, and then the server can use either HTTP/HTTPS with the operating system's internet CAs to retrieve the XML, verify the signatures, and so on.
Is the ICANN CA also an internet CA (i.e. a TLS domain CA)? We encourage developers to use HTTPS to retrieve the XML, but this seems like an attack vector:
Many countries MITM HTTPS traffic, which, depending on the server's internet CA collection, can and should cause the HTTPS download to fail DNS software may then fail open, or better implementations will fail closed. But this may still leave the administrator confused, which may cause them to disable DNSSEC altogether, rather than fix the internet CA issue or force HTTP over HTTPS. Retrieving the XML over HTTPS doesn't confer any additional security over simply verifying the signature of the ICANN CA in the separate signature file, in my opinion. It seems like we should recommend either HTTPS or verification of the separate signature.
What is the lifetime of the ICANN CA certificates, and how does this lifetime relate to the trust anchors? I.e. can we have a trust anchor whose lifetime exceeds the lifetime of the certificate used to sign the XML that certifies the trust anchor? How do embedded systems survive the rollover of the ICANN CA? I wasn't able to find the actual certificate for this, so I'm uncertain of when this would be a problem.
I expect that if we decide to answer some of these questions, it might be a separate best-practices RFC.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
paulehoffman
Hi Paul, Joe & Jakob,
I read the latest draft. One question I have, is what's the recommended procedure for a DNS server to bootstrap?
It seems like the ICANN CA certificate could be hard-coded into the software, and then the server can use either HTTP/HTTPS with the operating system's internet CAs to retrieve the XML, verify the signatures, and so on.
I expect that if we decide to answer some of these questions, it might be a separate best-practices RFC.