On Thu, Jun 1, 2023 at 3:22 PM Wes Hardaker <wjhns61@hardakers.net> wrote:

1. There is some definite disagreement in opinions we've heard at this point, where we've heard from the other extreme opinion where they actually wish we wouldn't support the old addresses beyond the TTL at the time of the changeover (IE, a bit longer than 48 hours).

Why? Are they fans of breaking the Internet? There is no TTL on the root hints file and software update cycles are generally a lot longer than 48 hours. Yes, I know resolvers are supposed to discard the hints once they have the authoritative NS and A records, but you'd just be begging for unintended consequences.

2. I'll note that we are still serving DNS requests at the addresses that we switched away from in 2017 [1][2]. At that time we actually only promised 6 months and we've doubled that time length with our latest announced change. But we do need a date after which we can turn off service to an address block if some reason demands it.

Certainly we would appreciate other opinions about what the right length of a change-over time would be, especially from the operational communities that will be most impacted by this change.

A server generation is about 3 years before it's obsolete and is generally replaced. I suggest making the old address operable for two generations (6 years) and black-holed for another generation (3 more years). Perhaps make it a false responder in the last of those 9 years so that anybody who is truly that far behind on their software updates gets enough of a spanking to stop sending you packets. You'll have problems repurposing the address and its subnet until folks stop sending you DNS query packets, even if you don't respond to them. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Thu, Jun 1, 2023 at 5:59 PM William Herrin <bill@herrin.us> wrote: A server generation is about 3 years before it's obsolete and is

generally replaced. I suggest making the old address operable for two . generations (6 years) and black-holed for another generation (3 more ....

As you mention.. there is No TTL for the root hints. The TTL is Infinite. And not all users will be retired after 3 years... there are DNS resolvers online running 10-year old code and there are DNS resolvers on the internet that may not see a roots hint update in the next 10 years. It is unlikely that there is any practical way of giving notice to the operators of such servers. Therefore, I would suggest IP Addresses that ever appeared in the official root hints should be reserved permanently and exclusively for official root service, then blackholed indefinitely once service is not in operation anymore to prevent any DNS service other than an official root server appearing at that IP at any point in time in the future no matter how many years have elapsed (Infinite TTL). A major concern would be if the IP address were eventually re-assigned to something else that ended up reporting false answers due to a malicious or misconfigured DNS service. DNS resolvers can handle no answer by trying other servers, but a false answer from an unauthorized and malicious root service being received by non-validating resolvers would be fairly certain to be capable of causing total failure in the resolver; while an IP address being offline would more likely only cause impairment or delays. It's understandable if some root service IP addresses stop providing service years after the end of service, and resolvers should still be able to function at some level with reduced resiliency and increased errors if only a small number have changed.

Regards, Bill Herrin

-- -JH

On Fri, Jun 2, 2023 at 10:40 AM William Herrin <bill@herrin.us> wrote:

On Fri, Jun 2, 2023 at 9:57 AM Jim <mysidia@gmail.com> wrote:

...

A major concern would be if the IP address were eventually re-assigned to something else that ended up reporting false answers due to a malicious or misconfigured DNS service.

Hi Jim,

That's one reason I suggested intentionally making it a false responder for the final year of its post-service hold. Return wildcard A and AAAA records for all queries pointing to a web site which responds to any URL with, "Hey buddy, your DNS software is so grossly out of date that now it's broken and will stay broken until you fix it."

Anybody still sending queries after that gets what they get and deserves it -- as long as the time that passes until the final year is long enough that only the most reckless and incompetent users are still sending queries.

I think you underestimate the time frames involved in some projects. My older brother was deeply involved in the James Webb space telescope project. At one point, while visiting him at the giant clean room in Redondo Beach, we started talking about the specifications on the computers onboard the telescope. I was aghast at how out-of-date the systems being installed were, and noted I could pop over to Fry's and pick up something with 20x the memory, running 10x as fast with pocket money. He countered by pointing out there were thousands of subcontractors involved in the project, and everything had to come together smoothly at the end. Once the design work was completed, *everything* was frozen; no changes were allowed, no matter how well-intentioned, because there could be unanticipated ripple effects on other components being worked on by completely independent subcontractors. The end result being that what was being launched was based on hardware and software that was finalized nearly two decades earlier. It's a bit unkind to think that only "reckless and incompetent users" will still be sending queries years later, when there are plenty of projects like the James Webb space telescope where the elements were locked in years before any decision to renumber root servers might have been made. I agree with Jim. Once a block was in use by a root server instance, encoded in root hints files, it should be forever reserved as such. If we want to make use of different RIRs and distribute responsibility around the planet, transfer the ownership of a block from one RIR to another; don't count on everything on and off the planet being able to update their root hints. Thanks! Matt

On Sat, Jun 3, 2023 at 12:46 PM Matt Corallo <nanog@as397444.net> wrote:

I assume RHEL would ship a root hints update during that time, but such things can slip through pretty easily as its not a security update.

Hi Matt, It *is* a security update. That's a really great point that I completely missed. After some period of time, the folks running b.root-servers.net should file a CVE against implementations still using the deprecated IP address. The CVE makes it a security issue compelling vendors of any still-supported software to issue an update. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Sat, Jun 3, 2023 at 8:46 PM Matt Corallo <nanog@as397444.net> wrote:

On 6/3/23 4:17 PM, William Herrin wrote:

...

It *is* a security update. After some period of time, the folks running b.root-servers.net should file a CVE against implementations still using the deprecated IP address.

Not really sure how you go about filing a CVE for a file that isn't usually a part of a standard software project -

https://downloads.isc.org/isc/bind9/9.18.15/bind-9.18.15.tar.xz grep -ri b.root-servers.net bind-9.18.15/ bind-9.18.15/lib/dns/rootns.c: ". 518400 IN NS B.ROOT-SERVERS.NET.\n" bind-9.18.15/lib/dns/rootns.c: "B.ROOT-SERVERS.NET. 3600000 IN A 199.9.14.201\n" bind-9.18.15/lib/dns/rootns.c: "B.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:200::b\n" bind-9.18.15/bin/named/config.c: 2001:500:200::b; # b.root-servers.net\n\ bind-9.18.15/bin/named/config.c: 199.9.14.201; # b.root-servers.net\n\ So, when 199.9.14.201 stops being a root DNS server, bind 9.18.15 legitimately has a CVE because that IP address is hard-coded. I would bet that the other major DNS server software also has some sort of mechanism for including the root hints instead of making the packager or user go fetch it. This is not a bad thing. Filing a CVE against it does not reflect badly on the programmers. It's a reasonable notification path for security folks to discover and address external changes that impact the security of the software they operate. -Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Sun, Jun 4, 2023 at 7:41 AM Izaac <izaac@setec.org> wrote:

It's not a security update. It's a configuration change.

Hi Izaac, Perhaps you missed my subsequent message where I pointed out that the IP address is hard-coded in Bind which will use it by default unless configured not to.

It's also not a vulnerability. A vulnerability, as defined by MITRE for CVE is:

"A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.

At an absolute minimum there's an impact to confidentiality since it causes Bind to announce itself to an IP address that is not a root server. If the user configured bind with DNSSEC validation disabled, it's also a negative impact to integrity and availability since the potential false responder can steer bind away from the true DNS tree. Like well known default passwords, for which there are many CVEs, it's a vulnerability. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Sun, Jun 4, 2023 at 4:57 PM Mark Andrews <marka@isc.org> wrote:

...

On 5 Jun 2023, at 06:19, William Herrin <bill@herrin.us> wrote: At an absolute minimum there's an impact to confidentiality since it causes

I don’t see a big risk here.

Hi Mark, I agree. CVEs are nevertheless issued for security problems where the risk is categorized as low. They often describe the mitigations available to address the risk as well, like installing an updated root hints file to override the compiled-in defaults. My point was not that there's some significant security risk to the root servers changing IP addresses. There isn't. My point is that there's enough of a security risk to a root server changing its IP address to merit CVEs against software statically distributed with the old address. That observation should be taken into account in any planning for the retirement of a root dns server's IP address. Such as the b-root change announced in this thread. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Sun, Jun 04, 2023 at 01:19:18PM -0700, William Herrin wrote:

Perhaps you missed my subsequent message where I pointed out that the

I did not.

IP address is hard-coded in Bind which will use it by default unless configured not to.

It is not "hard coded." It is a default configuration. You can change it. You are *supposed* to change it.

...

It's also not a vulnerability. A vulnerability, as defined by MITRE for CVE is:

"A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.

At an absolute minimum there's an impact to confidentiality since it causes Bind to announce itself to an IP address that is not a root server. If the user configured bind with DNSSEC validation disabled, it's also a negative impact to integrity and availability since the potential false responder can steer bind away from the true DNS tree.

First, you have completely ignored the argument: THERE IS NO FLAW IN COMPUTATIONAL LOGIC. There is no vulnerability. Second, the DNS protocol offers no guarantee of confidentiality. Is the protocol itself a vulnerability? Would you like to file a CVE against that? You are recommending embarking on a ludicrous journey ad absurdum. How about the web browser that makes a GET request via HTTP on port 80 before being 301'd over to HTTPS on 443? Or the web server that defaults to LISTEN on 80 and offer its success page without further configuration? Do I even need to cast a sideways glance at BGP? Perhaps you missed my message where I advised against abusing the already fragile de facto security notification mechanisms to propagate your desired configuration change. If the CVE process becomes inundated with configuration change notifications, it will cease to enjoy the timely attention which ought to be reserved for real, pants-soiling zero day vulnerabilities. But let's indulge a what-if: If some malicious party were to somehow wrestle control of the old address and begin offering false returns (which I cannot believe to be any worse than that some members on here already do with NXDOMAINs to their customers,) that situation will be handled by simply repeating the advisory of a configuration change. There exist mechanisms for notifying about network configuration changes. You are participating in at least one right now. In summary, it's not a vulnerability. Stop pushing CVE as an answer. It breaks far more than it would fix. All IANA can do (or is supposed to do) is publish the notice. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Wed, Jun 07, 2023 at 09:30:36AM -0700, William Herrin wrote:

Data embedded in the binary is hard-coded. That's what hard-coded means. If it makes you happier I'll qualify it as a "hard-coded default," to differentiate it from settings the operator can't override with configuration.

No. I will not indulge your invention of terms. "Hard-coded" means you need to recompile to change it. This is a default value. A configuration option takes precedence.

It's an instance of https://cwe.mitre.org/data/definitions/344.html

No, it is not in any respect. The code you grepped out generates a default configuration hints file when one does not exist. The CWE you cite specifically refers to default values for things like cryptographic RNG seeds and salts and TCP sequence number generators and the like. Viz something like https://www.debian.org/security/2008/dsa-1571 from 2008.

A quick search of https://cve.mitre.org/cve/search_cve_list.html shows between 600 and 3700 CVEs related to default configurations that are either directly insecure or unexpectedly become insecure when some but not all of the defaults are changed by the operator. The vast majority of these CVEs exhibit, as you say, no flaw in the computational logic.

You literally just gave me a link to the CVE search page, waved your hand, and said, "See?" Well, I'll admit to not being as good at conducting CVE research as you. So, as an expert on the topic: How many of these "between 600 and 3700 CVEs" are related to a violating the baseless expectation of confidentially in a protocol which does not guarantee confidentiality? Somewhere between 0 and 2000? But you know what, go ahead. Submit the CVE. Be the hero that you believe yourself to be. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Wed, Jun 07, 2023 at 03:46:39PM -0400, Michael Butler wrote:

...

No. I will not indulge your invention of terms. "Hard-coded" means you need to recompile to change it. This is a default value. A configuration option takes precedence.

BIND-9.18.14 requires recompilation to update the embedded defaults ..

bin/named/config.c: 2001:500:200::b; # b.root-servers.net\n\ bin/named/config.c: 199.9.14.201; # b.root-servers.net\n\ lib/dns/rootns.c: "B.ROOT-SERVERS.NET. 3600000 IN A 199.9.14.201\n" lib/dns/rootns.c: "B.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:200::b\n"

Don't comprehend what a vulnerability is. Don't recognize the distinction between a logic issue and a configuration issue. Don't understand the difference between "hard-coded" and a default value. Don't recognize that these defaults are overridden by a existing configuration file that is often shipped by the operating system distribution. Don't read the code. Be a co-author with Bill on the CVE. Go for it. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Wed, Jun 07, 2023 at 01:52:45PM -0700, William Herrin wrote:

[stuff]

Put it in your CVE. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Wed, Jun 07, 2023 at 02:45:05PM -0700, William Herrin wrote:

[more stuff]

I've unpacked what a vulnerability is and is not for you. I've unpacked how you can't be violating confidentiality in a protocol which doesn't guarantee confidentiality for you. I've unpacked how abusing the vulnerability reporting system for something which isn't actually a security vulnerability dilutes the effectiveness of that reporting system for you. I've unpacked basic definitions of basic terms like "hard-coded" for you. Each time, you've just quietly picked up the goal posts and moved them downrange. Your argument has gotten increasingly ridiculous. It's obvious that you're more interested in "winning" than anything. I've dispensed the last of my advise. File your CVE. I look forward to tracking its progress. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Thu, Jun 15, 2023 at 7:03 PM Wes Hardaker <wjhns61@hardakers.net> wrote:

All root server operators have made a strong commitment to only serving the DNS root as managed by IANA [1], I'm afraid this option is off the table. Although you could use some wiggle-ling to try and say this principle doesn't apply to "old addresses", I would not be willing to take that wiggle on behalf of b.root-servers.net.

Hi Wes, As I recall, the statement which started the thread could be paraphrased as one of those root server operating saying, "Hey Community, we'll continue to treat the old address as still a root DNS server for a year, maybe more, but no promises." I acknowledge that you'd prefer it be, "forever and a day," and perhaps that's what the answer should be, but in all due respect the document you cite is completely mute on the use of addresses which are -no longer- root DNS servers. At some point, somebody's going to want to do something with the old /24. If they didn't, nothing would stop them from committing to continue its use as a root DNS server (in addition to the new official address) for the remaining lifetime of the b-root service. The extra configuration and extra route announcement just don't have a high enough cost not to. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Thu, Jun 15, 2023 at 7:52 PM Wes Hardaker <wjhns61@hardakers.net> wrote:

William Herrin <bill@herrin.us> writes:

...

At some point, somebody's going to want to do something with the old /24.

You are correct that we did not state we will or will not be returning the address block we have back to ARIN. We do not plan on returning it for precisely the reasons you've specified. Even if we were going to, we would certainly stop responding on it for a long time first. And even if we returned it, I suspect that ARIN itself would consider carefully what to do with a returned address in the critical infrastructure block.

Hi Wes, Due respect, you should have a better fleshed-out commitment to the community than, "Here today, gone tomorrow. Probably not. Maybe." Not to put words in your mouth, but try something like, "We will continue serving root DNS requests from the old address indefinitely. We will notify the community of any change in that disposition at least 1 year prior to the change and will describe, at that time, what will change." Don't say, "We'll keep it up for as long as we feel like it, but at least a year." That's crap.

TL;DR: we agree and it's covered.

Say the words. THEN we agree that it's covered. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On 6/17/23 7:12 AM, Tom Beecher wrote:

Bill-

Don't say, "We'll keep it up for as long as we feel like it, but at least a year." That's crap.

30% of the root servers have been renumbered in the last 25 years.

h : 2015 d: 2013 l : 2007 j : 2002

For these 4 cases, only a 6 month transition time was provided, and the internet as we know it did not fall over in a flaming pile. ( One could argue it was ALREADY a flaming pile, but that's a different discussion.)

There’s a huge difference between “no one noticed any issues because recursive resolvers will seamlessly fall back to other root servers if there’s an outage” and “there aren’t issues”. For non-DNSSEC-verifying-resolvers (sheesh, but they still exist), if the IPs are eventually released and someone stands up a DNS server on them you could cause real harm. Does this need to be over-engineered to prevent that? No, though doing a few tricks to help the poor folks on unmaintained recursive resolvers isn’t bad either. But lack of visible issues doesn’t mean that users aren’t put at risk. That said, I have no idea if the old number resources were released or no longer announced in the DFZ after the previous renumbers, which would really be the point at which concern is warranted, not simply no longer responding. Matt

That's great in theory, and folks should be using DNSSEC [1], but we all know there's plenty of places out there in this wide world that don't do things right, and absolutely *do* rely on packets getting to the correct place. I'm not saying we shouldn't whack those folks with a cluestick [1] (we should), I'm saying we should also not bother making it easier for an attacker to hijack these poor misguided souls. Matt [1] $(dig +short pumpkey.net ds) returns nothing here, so I guess you are included in the set of folks who should really upgrade their DNS security to stop relying on the trust packets are getting to the right place. On 6/17/23 6:05 PM, Crist Clark wrote:

IP addresses cannot and should not be trusted. It’s not like you can really trust your packets going to B _today_ are going to and from the real B (or Bs).

If the security of DNS relies on no one intercepting or spoofing responses of some of your queries to a root server, it’s been game over for a long time.

On Sat, Jun 17, 2023 at 10:29 AM Matt Corallo <nanog@as397444.net <mailto:nanog@as397444.net>> wrote:

On 6/17/23 7:12 AM, Tom Beecher wrote: > Bill- > >     Don't say, "We'll keep it up for as long as we feel like it, but at >     least a year." That's crap. > > > 30% of the root servers have been renumbered in the last 25 years. > > h : 2015 > d: 2013 > l : 2007 > j : 2002 > > For these 4 cases, only a 6 month transition time was provided, and the internet as we know it did > not fall over in a flaming pile. ( One could argue it was ALREADY a flaming pile, but that's a > different discussion.)

There’s a huge difference between “no one noticed any issues because recursive resolvers will seamlessly fall back to other root servers if there’s an outage” and “there aren’t issues”.

For non-DNSSEC-verifying-resolvers (sheesh, but they still exist), if the IPs are eventually released and someone stands up a DNS server on them you could cause real harm.

Does this need to be over-engineered to prevent that? No, though doing a few tricks to help the poor folks on unmaintained recursive resolvers isn’t bad either.

But lack of visible issues doesn’t mean that users aren’t put at risk. That said, I have no idea if the old number resources were released or no longer announced in the DFZ after the previous renumbers, which would really be the point at which concern is warranted, not simply no longer responding.

Matt

On 6/18/23 12:53 AM, Masataka Ohta wrote:

Matt Corallo wrote:

...

That's great in theory, and folks should be using DNSSEC [1],

Wrong.

Both in theory and practice, DNSSEC is not secure end to end

Indeed, but (a) there's active work in the IETF to change that (DNSSEC stapling to TLS certs) and (b) that wasn't the point - the above post said "It’s not like you can really trust your packets going to B _today_ are going to and from the real B (or Bs)." which is exactly what DNSSEC protects against! It may not protect the client, but it protects the recursive resolver, which is often on the same AS as the client (or if its not, its usually connected via DoH/DoT, which is itself a secure channel).

and is not very useful.

If its not useful, please describe a mechanism by which an average recursive resolver can be protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the announcement at all, last I heard) and responding with bogus data? Or, alternatively, describe a mechanism which allows a recursive resolver to not return bogus data in the case of *any* authoritative server BGP hijack.

For example, root key rollover is as easy/difficult as updating IP addresses for b.root-servers.net.

Then maybe read the rest of this thread, cause lots of folks pointed out issues with *just* updating the IP and not bothering to give it some time to settle :) Matt

Naturally C root is fine on HE over IPv4, the issue is with IPv6. 2001:500:2::c is not reachable over HE. -Cynthia On Sun, Jun 18, 2023 at 8:10 PM <niels=nanog@bakker.net> wrote:

* nanog@as397444.net (Matt Corallo) [Sun 18 Jun 2023, 19:12 CEST]:

...

If its not useful, please describe a mechanism by which an average recursive resolver can be protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the announcement at all, last I heard) and responding with bogus data?

No comment on DNSSEC but lg.he.net indicates that they do in fact carry a route to C-root: --- 1 76 ms * * port-channel2.core2.pao1.he.net (72.52.92.65) 2 44 ms 63 ms 78 ms palo-b24-link.ip.twelve99.net (195.12.255.209) 3 55 ms 66 ms 103 ms cogent-ic-344188.ip.twelve99-cust.net (62.115.174.65) 4 74 ms 57 ms 120 ms be2431.ccr41.sjc03.atlas.cogentco.com (154.54.88.189) 5 142 ms 99 ms 79 ms be3142.ccr21.sjc01.atlas.cogentco.com (154.54.1.193) 6 53 ms 75 ms 111 ms be3176.ccr41.lax01.atlas.cogentco.com (154.54.31.189) 7 82 ms 133 ms 85 ms te0-0-2-0.c-root.lax01.atlas.cogentco.com (154.54.27.138) 8 60 ms 152 ms 84 ms c.root-servers.net (192.33.4.12) Entry cached for another 60 seconds. 2023-06-18 17:57:17 UTC ---

I don't see any ROAs for AS2149's two originated prefixes, though: https://irrexplorer.nlnog.net/prefix/192.33.4.0/24 so hijacks might still be easier than they could be.

Regards

-- Niels.

Matt Corallo wrote:

...

Both in theory and practice, DNSSEC is not secure end to end

Indeed, but (a) there's active work in the IETF to change that (DNSSEC stapling to TLS certs)

TLS? What? As was demonstrated by diginotar, PKI is NOT cryptographically secure and vulnerable to MitM attacks on intermediate intelligent entities of CAs. Note that diginotar was advertised to be operated with HSMs and four-eyes principle, which means both of them were proven to be untrustworthy marketing hypes.

and (b) that wasn't the point - the above post said "It’s not like you can really trust your packets going to B _today_ are going to and from the real B (or Bs)." which is exactly what DNSSEC protects against!

As long as root key rollover is performed in time and intermediate zones such as ccTLDs are not compromised, maybe, which is why it is not very useful or secure. The following description https://en.wikipedia.org/wiki/DigiNotar Secondly, they issued certificates for the Dutch government's PKIoverheid ("PKIgovernment") program. This issuance was via two intermediate certificates, each of which chained up to one of the two "Staat der Nederlanden" root CAs. National and local Dutch authorities and organisations offering services for the government who want to use certificates for secure internet communication can request such a certificate. Some of the most-used electronic services offered by Dutch governments used certificates from DigiNotar. Examples were the authentication infrastructure DigiD and the central car-registration organisation Netherlands Vehicle Authority [nl] (RDW). makes it clear that entities operating ccTLDs may also be compromised.

If its not useful, please describe a mechanism by which an average recursive resolver can be protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the announcement at all, last I heard) and responding with bogus data?

As DNSSEC capable resolvers are not very secure, you don't have to make plain resolvers so secure.

...

For example, root key rollover is as easy/difficult as updating IP addresses for b.root-servers.net.

Then maybe read the rest of this thread, cause lots of folks pointed out issues with *just* updating the IP and not bothering to give it some time to settle :)

In this thread, I'm the first to have pointed out that old IP addresses of root servers must be reserved (for 50 years). Masataka Ohta

Matt Corallo wrote:

...

Note that diginotar was advertised to be operated with HSMs and four-eyes principle, which means both of them were proven to be untrustworthy marketing hypes.

Even more reason to do DNSSEC stapling!

See hypes of HSMs and four-eyes from DNSSEC operators.

This is totally unrelated to the question at hand. There wasn't a question about whether a user relying on trusted authorities can maybe be whacked by said trusted authorities (though there's been a ton of work in this space, most notably requiring CT these days),

So, let's recognize ISPs as trusted authorities and we are reasonably safe without excessive cost to support DNSSEC with all the untrustworthy hypes of HSMs and four-eyes principle.

it was purely about whether we can rely on pure "I sent a packet to IP X, did it get to IP X", which *is* solved by DNSSEC.

That's overkill. See above for the proper solution. Masataka Ohta

Matt Corallo wrote:

...

So, let's recognize ISPs as trusted authorities and we are reasonably safe without excessive cost to support DNSSEC with all the untrustworthy hypes of HSMs and four-eyes principle.

I think this list probably has a few things to say about "ISPs as trusted authorities"

I'm afraid you miss the point. My point is that trusted third parties of CAs including DNSSEC providers are at least as untrustworthy as ISPs.

- is everyone on this list already announcing and enforcing an exact ASPA policy (or BGPSec or so) and ensuring the full path for each packet they send is secure and robust to ensure it gets to its proper destination?

I'm afraid that is a hype as bad as HSMs and four-eyes principle.

Somehow I don't think this model is workable,

As PKI, including DNSSEC, is subject to MitM attacks, is not cryptographically secure, does not provide end to end security and is not actually workable, why do you bother? Masataka Ohta

Matt Corallo wrote:

...

As PKI, including DNSSEC, is subject to MitM attacks, is not cryptographically secure, does not provide end to end security and is not actually workable, why do you bother?

It sounds like you think nothing is workable, we simply cannot make anything secure

If an end and another end directly share a secret key without involving untrustworthy trusted third parties, the ends are secure end to end.

- if we should give up on WebPKI (and all its faults) and DNSSEC (and all its faults) and RPKI (and all its faults), what do we have left?

An untrustworthy but light weight and inexpensive (or free) PKI may worth its price and may be useful to make IP address based security a little better. Masataka Ohta

Mark Andrews wrote:

...

If an end and another end directly share a secret key without involving untrustworthy trusted third parties, the ends are secure end to end.

...

An untrustworthy but light weight and inexpensive (or free) PKI may worth its price and may be useful to make IP address based security a little better.

Which you can do with DNSSEC but the key management will be enormous.

Which part of my message, are you responding? First part? Though you might have forgotten, my initial proposal of DNSSEC actually allows to use both public and shared keys. Having hierarchical KDCs (Key Distribution Centers), instead of hierarchical CAs, key management is not enormous. Shared key is better than public key, because revocation is instantaneous. Instead, root KDCs receive large amount of requests. But, situation is similar to DNS root servers today and is manageable. Kerberos relies on KDCs. However, the shared keys are shared by ends and intermediate systems of KDCs, which is not end to end security. Masataka Ohta

On 2/06/2023 at 10:22:46 AM, Wes Hardaker <wjhns61@hardakers.net> wrote:

2. I'll note that we are still serving DNS requests at the addresses that we switched away from in 2017 [1][2]. At that time we actually only promised 6 months and we've doubled that time length with our latest announced change. But we do need a date after which we can turn off service to an address block if some reason demands it.

Hi Wes, Seems to me that this could be heavily informed by historical data from this earlier renumbering. Do you have query rates over time for the old and new addresses since this change in 2017? Even if you end up with the same answer of 12mo, data supporting it may give comfort to the community. Maybe you make a call that once it’s at say 1% or 0.1% or something like that, then it’s OK to turn off - and make a prediction for when that might be based on the historical data. -- Nathan Ward

Nathan Ward <lists+nanog@daork.net> writes: Hi Nathan, [Sorry for the delay -- this was ICANN week and I'm just getting unburied]

Do you have query rates over time for the old and new addresses since this change in 2017?

We do indeed still get traffic on the older addresses, and its not an insignificant amount and its not just priming queries either.

Even if you end up with the same answer of 12mo, data supporting it may give comfort to the community.

As my colleague Robert Story said in a separate thread, we are still serving our old address and will almost certainly continue to serve our current address long beyond the promise date we put into the announcement. Our intent is to continue serving it longer than the announced end date, but we do not offer a promise to do so. -- Wes Hardaker USC/ISI