[106884] in North American Network Operators' Group
RE: Validating rights to announce a prefix (was: Public shaming...)
daemon@ATHENA.MIT.EDU (Skywing)
Fri Aug 15 10:56:15 2008
From: Skywing <Skywing@valhallalegends.com>
To: "michael.dillon@bt.com" <michael.dillon@bt.com>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Fri, 15 Aug 2008 09:56:05 -0500
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC078EECD6@E03MVZ2-UKDY.domain1.systemhost.net>
Errors-To: nanog-bounces@nanog.org
<security person rant>
"Easy upgrade" to PKI after the fact might as well be a misnomer. In parti=
cular, there will likely be no way to ensure that nobody uses the old syste=
m instead of the new, spiffy and "secure"-ified system. This means that su=
pport for the old, "insecure" system must be kept around indefinitely, for =
all practical considerations - which opens you to downgrade attacks and all=
sorts of other unpleasantness from the backwards compatibility baggage inv=
olved.
Now, it may well be that we don't need a full blown PKI here, but I think t=
hat we should be extremely wary of any scheme that proposes to be future up=
gradeable to be "more secure", especially when we are talking about a mostl=
y decentralized system where there isn't going to be much of a practical pu=
sh to force people to upgrade.
At the risk of opening the door to much flame-age, consider that with dnsse=
c, my understanding here is that we will *still* have to keep around suppor=
t for non-secured queries for a very, very long time until everyone (or som=
e level of "everyone" that we consider "good enough", which is also unlikel=
y to be the case for a very long time) runs dnssec-ified authoritative name=
servers for their domains. This means that the non-secured "plain" DNS pa=
th will continue to remain open for attack for years to come, even if every=
one on this list, and the root/gTLDs/cccTLDs magically stopped what they we=
re doing right now and somehow rolled out dnssec tomorrow. Being forced to=
keep this code around leaves you open to downgrade attacks.
To give a quick example off the top of my head of why this can be dangerous=
, consider the following back-of-the-napkin scenario:
Even with signature expiration times in place in dnssec to try and prevent =
replaying of old signed zones that would allow downgrade attacks for any do=
mains not listed as supporting dnssec, an adversary in your packet path can=
still (probably) have a reasonable shot at successfully forcing a downgrad=
e attack and subsequently spoofing data using "plain" DNS fallback. For ex=
ample, to validate validity timestamps on signatures, you need to have vali=
d local system time, and how do you update your local system time? Do you =
use NTP over the public Internet? If so, an attacker in your packet path c=
an change your system time and replay old dnssec signatures, thus allowing =
downgrade attacks for domains that were previously not using dnssec by taki=
ng advantage of "plain" DNS fallback code.
Now, I'm not really trying to bash dnssec here, but rather point out that "=
upgrading" to something that's secure later on should be considered practic=
ally a non-option in a (mostly) decentralized scenario like how the global =
routing DFZ is managed. I'm also not trying to bash your proposal specific=
ally (or the level of security it provides), but rather just call attention=
to the uncomfortableness to anything that provides "soft" security from th=
e get-go with a later option for upgrade to "hard" security.
</security person rant>
Now, it may well be that we really don't need PKI here for reasonable secur=
ity (and I am explicitly *not* commenting on whether this is or is the case=
here), but we had better be damn sure that we make the right call there be=
fore rolling anything like this out, or we'll be dealing with the security =
consequences for a very long time to come.
There are just *so* many things that make handling a "secure" upgrade to a =
well-entrenched protocol that provides "hard" security, while keeping reaso=
nable functionality an extremely difficult task (to say the least), that yo=
u would likely almost be better scrapping the existing (well, new) protocol=
entirely and coming up with a new one from scratch should such prove neces=
sary.
- S
-----Original Message-----
From: michael.dillon@bt.com [mailto:michael.dillon@bt.com]
Sent: Friday, August 15, 2008 5:55 AM
To: nanog@nanog.org
Subject: RE: Validating rights to announce a prefix (was: Public shaming...=
)
> Okay, I admit I haven't paid the closest attention to RPKI,
> but I have to ask: Is this a two-way shared-key issue, or
> (worse) a case where we need to rely on a central entity to
> be a key clearinghouse?
>
> The reason why I mention this is obvious -- the entire PKI
> effort has been stalled (w.r.t. authority) because of this
> particular issue.
Who says there needs to be a PKI infrastructure in order to
do this? There are other ways of authenticating data. For instance
ARIN could hold the data that they have validated on their own
servers and people could use HTTPS queries to ensure that they
get the answers that they thought they would get.
As for how the address owner delegates the right to announce
a prefix, they could either operate their own database and
ARIN would have a pointer to it, or they could register the
data in ARIN's database by some secure means. There is no
reason why "secure means" could not include various out of
band authentication systems.
People are too hung up on cryotographically secure PKI systems
which are way overkill for this problem. In fact, it should be
possible to design an architecture that allows for an easy upgrade
to PKI if it should be determined at some future date, that PKI
is necessary.
--Michael Dillon
