RE: Validating rights to announce a prefix (was: Public shaming...)

[<michael.dillon () bt com>]

> "Easy upgrade" to PKI after the fact might as well be a 
> misnomer.  In particular, there will likely be no way to 
> ensure that nobody uses the old system instead of the new, 
> spiffy and "secure"-ified system.  This means that support 
> for the old, "insecure" system must be kept around 
> indefinitely, for all practical considerations

This is nonsense. If I can shut down my gopher server, then
why can't someone stop accepting delegation notifications that
don't meet the requirements of version x+1 for some value of x?

For that matter, since cleanliness of data is a major problem
in this type of database, why can't all records expire 6 months
after they are entered? That would avoid the garbage that collects
in IRR or whois databases. If an entity is not active and does not
refresh their delegation of prefix announcement rights, then
after 6 months, their connectivity will begin to crumble as the 
various providers refresh their route filters from their OSS
systems.

> Now, it may well be that we don't need a full blown PKI here, 
> but I think that we should be extremely wary of any scheme 
> that proposes to be future upgradeable to be "more secure", 
> especially when we are talking about a mostly decentralized 
> system where there isn't going to be much of a practical push 
> to force people to upgrade.

You mean version incompatibility leading to an inability to
refresh your expired data, is not enough of a push? If that
is so, then why are you routing their traffic?

> At the risk of opening the door to much flame-age, consider 
> that with dnssec, my understanding here is that we will 
> *still* have to keep around support for non-secured queries 
> for a very, very long time until everyone 

That is a different situation even though there are similarities.

> 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 domains not listed as 
> supporting dnssec, an adversary in your packet path can still 
> (probably) have a reasonable shot at successfully forcing a 
> downgrade attack and subsequently spoofing data using "plain" 
> DNS fallback.  For example, to validate validity timestamps 
> on signatures, you need to have valid 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 can change your system time and replay old dnssec 
> signatures, thus allowing downgrade attacks for domains that 
> were previously not using dnssec by taking advantage of 
> "plain" DNS fallback code.

This is why these fully automated crypto PKI solutions make me
uneasy. There is too darn much complexity and too little experience
with them in the real world. If you move the problem to a different
space where OSS systems check route delegations, and only update
router configs after some human intervention then there is less
chance of wierd attack vectors succeeding.

>  I'm also not trying to bash your proposal 
> specifically (or the level of security it provides), but 
> rather just call attention to the uncomfortableness to 
> anything that provides "soft" security from the get-go with a 
> later option for upgrade to "hard" security.

If I agreed with you, I never would have set up an ISP back
in 1994 because of the fundamental insecurity of an IPv4
Internet without IPSEC support baked into the fundamental
protocol. 

> There are just *so* many things that make handling a "secure" 
> upgrade to a well-entrenched protocol that provides "hard" 
> security, while keeping reasonable functionality an extremely 
> difficult task (to say the least), that you would likely 
> almost be better scrapping the existing (well, new) protocol 
> entirely and coming up with a new one from scratch should 
> such prove necessary.

See, there is a straightforward upgrade route after all.
Even more straighforward if we walk into this with clear
requirements and a clear documented architecture so that
everyone knows what the boundaries are and fewer people
bake things into hard-to-upgrade places. 

--Michael Dillon