-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe,
On 08/30/2009 03:05 AM, Joe Abley wrote: >>>> Well, in practice that means someone holding such a software >>>> update key. That does not change at all. For 20 years or so? >>>> I do not see how this would be more secure. >>> >>> It at least matches the security in the rest of the operating system, I >>> guess. >> >> So, how do you propose I manage the unbound validator root trust >> anchor distribution? > > Personally, I think the right behaviour for a fresh installation of old > software, or a sudden resurrection of a long-disconnected host is to > fail and require operator intervention. That does not match my expectations for end-users. Though, perhaps, ISP or companies are different. So, for end-users, the operator intervention consists of calling the help-line, or reinstalling the system? Of course a system reinstall uses the software-update key. Yeah, failure is a secure option. No longer useful, but secure. >> [...] >> >> So, your concern is a compromised key. Which people use to divert >> old machines (thus, 4 year old machines or so?) down a bad path. > > Yeah. > >> Of course the draft already contains a mechanism to make such >> attempts highly visible, did you consider those mechanisms? > > I'm not seeing it. I would be grateful if you could point out more > explicitly what I'm missing. Sorry, I thought you had seen it: The draft specifies that all the upstream nameservers MUST be checked if they provide the same DNSKEY keyset for the target zone. This is a probe for the current keyset, that looks like others probes for the current keyset by other validators that are just starting up. So, for sniffers or MitM, the first query looks like all the others. Its result is the current keyset. Which it is going to verify. Then the other nameservers are checked too (some rollover logic here), and this makes sure that not only have you probed a couple of times, but also that if you get some sort of bogus answer, that answer comes from all of the servers (this fixed Ted Lemon's attack scenario). So, either you get the correct keyset at this stage, and the algorithm basically can only be DoSed from then on; or end happily. (with a cracked key, some spoofer may present an alternative history, but that detour in the keychain ends with the valid current keys, so, that doesn't make a difference. It can detour to a revocation). Or, you do not get the correct keyset at this stage. That means all the upstream nameservers are serving a bogus DNSKEY for the current keyset of the target zone. This is pretty severe from a wider perspective, for the other users. This means that all other users, who have valid keys, cannot start their validators, and use the internet. The ISP is likely to get notified that something is amiss. Of course, the victim is (indeed) not aware of this. And may then get wrong keys. But now the second part of the algorithm tries to make it harder again: (see below, where you setup a key chain) So, the attacker has to limit his spoofing (or MitMing) scope to only the people using history lookups, but again the above is making that hard, since the history lookup starts out camouflaged as a normal validator startup. >> So, what exactly are you afraid of, can you give more details? > > Suppose the root zone trust anchor is rolled periodically. > > The legitimate trust anchors follow a series A0, A1, A2, A3, A4, A5, A6, > ..., Ai, ... > > Suppose an attacker obtains the secret key for which A3 is the > corresponding public key, either by energetic factoring or by a key > compromise. I think it's clear that this is a threat, the former more > likely than the latter, perhaps, given sound key hygiene by the KSK > operator and sufficient time to factor an old key. Because the history is looked up *in reverse*, the attacker does not know which key the victim is holding. Until he uses it. If the victim is holding key A5, then his spoof of the upstream nameservers, and this history spoof was in vain, since he has not cracked it. The history lookup fails. And the user may well phone his ISP since there is some intrusion going on. If the victim is holding key A1, then the victim accepts the fake final keyset: B6. > Suppose that attacker is able to poison caches or otherwise introduce > bogus data to clients. I presume this is a recognised threat, given that > this is one of the problems that DNSSEC deployment is intended to fix. > > Then it seems possible that an attacker could introduce (through your > proposed mechanism) a trust anchor series A0, A1, A2, A3, B4, B5, B6, > ..., Bi, ... where Bi is a trust anchor to a rogue key. > > It also seems possible that an attacker could obtain the real root zone, > replace the KSK with a key to which Bi refers, replace the ZSK and > re-sign with existing DS records. ok. > A client which has been polluted with both sets of data then has an > apparently-valid trust anchor for the root zone, but the contents of the > root zone are no longer signed by the correct authority, but rather by > the attacker. Well yes, but he only trusts B6 now. As soon as the victim no longer receives spoofs from the attacker, then he will see the real root key; and everything fails for him. Which leads to the ISP being notified. It occurs to me that perhaps you think the client is storing all of the intermediate states? That the client is storing A1,...A3, B4..B6? No the client only stores the latest key, which since it runs in reverse, is the first thing it probes. > The attacker can now introduce whatever she wants to the root zone, and > have validators infer trust from the signatures that accompany the bad > data. > I do not see how this introduction of rogue, signed data is identifiable > from the client. Well, I cannot disagree in the cryptographic sense. If the attacker is strong enough, and breaks all the above. Thus it is full MitM, it knows the identity of old-key-using-machines, and it knows which keys they are holding (i.e. machines which keys before A3). (not a full MitM: several initial lookups and a (long?) history chain, block a failure-prone blind spoofing). Also, the current draft has more protection mechanisms that I did not mention yet: KSK needs to be compromised not ZSK. Dates move forward no replay. Timer so the attacker cannot use trust history quickly if the *current* key is compromised. [And in -02, timer can be adjusted, so the zone owner can choose a short timer if he wants to roll very quick if compromised]. > That being the case, it seems possible that a long-lived, systematic > attack could cause a gradually increasing population of clients who have > invalid trust anchors to exist in the world, such that at some point > harmful data could be introduced to the root zone by the attacker which > would have significant impact (i.e. a large number of clients would > accept it). So, assuming that the attacker defeats all the other protection mechanisms, and installs fake root KSKs into some victim. How does that fake KSK keep working? The attacker needs to stay MitM as well? As soon as it stops the MitM, those clients have failures, and presumably are repaired. So, the long-lived only happens if the MitM control is also long-lived. >> measurable? So, you can measure calls about spoofed root keys and possibly even support calls from people who were attacked. > I'm not promoting any other mechanism as being globally useful. I'm > criticising the particular mechanism you proposed. Ok, that is perfectly valid. Happy to get the criticism, really, as I want to put out something that is properly secure ... > Other users will have different mechanisms. Well if this doesn't work, I need something else. And you assume key A3 can be compromised. But any system would be vulnerable to the trusted key being compromised? I mean, really, any system that consist of a trusted key on a system that it uses, (software update, history lookup or some other way), can be compromised in the same way? Just like key A3 is broken above, that key can be broken, and the above has lots of added extra mechanisms that help by making sure the attacker needs extra powers. And other systems do not have that. I am certainly interested in alternatives (this line is aimed at dnsop, Joe already answered). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqbmNAACgkQkDLqNwOhpPjtFACgh6rw5BF286LwNx5VcZ5YUS9k 20gAn3v/oiCLj9qr++Bf97Mod7kvmmp2 =BIS8 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
