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
Which you can do with DNSSEC but the key management will be enormous.
--
Mark Andrews
> On 21 Jun 2023, at 15:39, Masataka Ohta
> wrote:
>
> Matt Corallo wrote:
>
>>> As PKI, including DNSSEC, is subject to MitM attacks, is
>>> not cryptographically secure, does not provide end to end
>>>
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
On 6/20/23 10:20 PM, Masataka Ohta wrote:
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
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"
On 6/19/23 8:08 PM, Masataka Ohta wrote:
Matt Corallo wrote:
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
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
On 6/19/23 2:08 AM, Masataka Ohta wrote:
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
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
* nanog@nanog.org (Cynthia Revström via NANOG) [Sun 18 Jun 2023, 20:52 CEST]:
Naturally C root is fine on HE over IPv4, the issue is with IPv6.
2001:500:2::c is not reachable over HE.
You're absolutely correct. Maybe their LG defaulting to IPv6 made my
brain short-circuit. (Their looking
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 wrote:
>
> * na...@as397444.net (Matt Corallo) [Sun 18 Jun 2023, 19:12 CEST]:
> >If its not useful, please describe a mechanism by which an average
* na...@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)
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)
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 and is not very useful.
For example, root key rollover is as easy/difficult as
updating IP addresses for b.root-servers.net.
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]
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
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
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
On Jun 15, 2023, at 10:51 PM, Wes Hardaker wrote:
>> 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
On Thu, Jun 15, 2023 at 7:52 PM Wes Hardaker wrote:
> William Herrin 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
William Herrin writes:
Hi Bill,
> 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.
I cited the document
On Thu, Jun 15, 2023 at 7:03 PM Wes Hardaker 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
Nathan Ward 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
Matt Corallo writes:
[Sorry for the delay -- this was ICANN week and I'm just getting unburied]
> > 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
Mark Andrews wrote:
The commitment to maintain service for 1 year after the new LACNIC
addresses are switched in to the root.hints from IANA does not mean that
this is a cutoff date and that we intend to turn off service on the
older addresses after a year. We currently have no plans to do so
> On 9 Jun 2023, at 14:29, Masataka Ohta
> wrote:
>
> Robert Story wrote:
>
>> The commitment to maintain service for 1 year after the new LACNIC
>> addresses are switched in to the root.hints from IANA does not mean that
>> this is a cutoff date and that we intend to turn off service on
Robert Story wrote:
The commitment to maintain service for 1 year after the new LACNIC
addresses are switched in to the root.hints from IANA does not mean that
this is a cutoff date and that we intend to turn off service on the
older addresses after a year. We currently have no plans to do so
On Wed 2023-06-07 15:34:12-0700 Matthew wrote:
> If the goal is increased robustness by having addresses present from a
> different RIR, wouldn't it make this whole tempest in a teapot moot
> if, instead of *reunubering*, you simply *added* a second set of IPs,
> but continued to answer queries on
Mark Andrews wrote:
It announces itself to an address which remains under the control of
USC/ISI the current and on going root server operator for b.root-servers.net.
So apart from leaking that the root hints have not been updated I don’t
see a big risk here. The address block, as has been
Hi Robert,
If the goal is increased robustness by having addresses present from a
different RIR,
wouldn't it make this whole tempest in a teapot moot if, instead of
*reunubering*, you
simply *added* a second set of IPs, but continued to answer queries on the
original
addresses as well?
Is there
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
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 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
On 6/7/23 15:13, Izaac wrote:
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
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.
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.
On Sun, Jun 4, 2023 at 4:57 PM Mark Andrews wrote:
> > On 5 Jun 2023, at 06:19, William Herrin 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
On Sat 2023-06-03 23:00:33+0200 Terrence wrote:
> Forgive me if I'm missing something obvious, but why are you
> renumbering at all?
>
> Of course the diversification of RIRs is a good thing, but couldn't
> that be accomplished just as well by transferring the current
> allocation to LACNIC?
Hi
On Sat, Jun 03, 2023 at 04:17:41PM -0700, William Herrin wrote:
> 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.
On Sat, Jun 3, 2023 at 8:46 PM Matt Corallo 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
On 6/3/23 4:17 PM, William Herrin wrote:
On Sat, Jun 3, 2023 at 12:46 PM Matt Corallo 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
On Sat, Jun 3, 2023 at 12:46 PM Matt Corallo 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
: New addresses for b.root-servers.net
>
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> USC/ISI will continue to support root service o
On 6/1/23 3:57 PM, William Herrin wrote:
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
On Fri, Jun 2, 2023 at 10:40 AM William Herrin wrote:
> On Fri, Jun 2, 2023 at 9:57 AM Jim 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
On Fri, Jun 2, 2023 at 9:57 AM Jim 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
On Thu, Jun 1, 2023 at 5:59 PM William Herrin 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
I know when I did the openresolver project stuff I saw a number that would send glue or referrals from before they moved to the root servers domain names. - Jared Sent via RFC1925 compliant deviceOn Jun 2, 2023, at 8:49 AM, Nathan Ward wrote:
On 2/06/2023 at 10:22:46 AM, Wes Hardaker
On 2/06/2023 at 10:22:46 AM, Wes Hardaker 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
William Herrin wrote:
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.
Considering the possibility that, in a long run, remaining
12 sets (4 and 6) of
On Thu, Jun 1, 2023 at 3:22 PM Wes Hardaker 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
Jan Schaumann via NANOG writes:
> > USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> > b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> > 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> > USC/ISI will continue to support root service over our current
Robert Story wrote:
>
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> USC/ISI will continue to support root service over our current IPv4 and
> IPv6
USC/ISI is renumbering both its IPv4 and IPv6 addresses for
b.root-servers.net on 2023-11-27. Our new IPv4 address will be
170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
USC/ISI will continue to support root service over our current IPv4 and
IPv6 addresses for at least one year
54 matches
Mail list logo
