Subject: [DNSOP] new version: trust-history-02 draft

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 21 Aug 2009 16:08:56 +0200

Hi,

http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02

Is available for review and comment.  This represents my take on how
to perform trust-anchor management for a validator without having
a system update mechanism (which works with unsafe DNS).

I have incorporated substantial comments and feedback.

o From Ted Lemon, Fixed the 'poison one upstream server'-attack.
o From Bert Hubert, Fixed the 'history in reverse'-attack.
o From Ed Lewis, Fixed so keys do not 'last forever'.
o From Mark Andrews, considerations for 5011-revocation.
o From Steve Crocker, Easy to test.
o From Bill Manning, can work on its own.
o From Wolfgang Nagele, zone owner advertising and 30days tweakable.
o From Olaf Kolkman, made the text easier to understand.
And more, sorry if I forgot here.

There is exactly one open issue:
o Publication of expired RRSIGs.
[ various people, Ed Lewis, Olaf Kolkman ]
This specification puts expired RRSIGs into the DNS and expects them
to be delivered.  What about 'smart' boxes that remove expired
signatures?  I think that boxes are not allowed to remove 'expired'
signatures.  This is why we have the CD flag.  This is good to put
into dnssec-bis-updates?
One solution may be a 'HISTORICAL_RRSIG' new type.  Which needs a
new type allocation, where perhaps RRSIG serves perfectly fine.
Also RRSIG is sent with a DNSKEY answer.  HISTORICAL_RRSIG
causes extra queries to get it.

Best regards,
   Wouter

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Aug 2009 21:22:30 -0400

> a system update mechanism (which works with unsafe DNS).

I don't remember whether I've expressed my concerns about this work in  
e-mail before. I remember talking to people in Stockholm about it.

Keys are rolled for a reason. You can't always tell from the outside,  
as an automated device, what the reason was -- it could be that it's a  
conservative defence against a possible factoring attack having been  
executed within a particular time, or it could be due to a key  
compromise.

A historical key has been replaced by a new one. A historical key is  
not to be trusted. Signatures made by a historical key are not to be  
trusted.

This work seeks to solve a real problem, as far as I can see -- the  
problem of how a validator which has been disconnected from the  
network for some period of time can bootstrap itself based on a trust  
anchor that was once good.

It's not clear to me that using signatures from keys which are known  
not to be trusted is a good way for such validators to bootstrap  
themselves. In fact, I suggest that in general it's a bad way to do  
it, since in the event of key compromise the result could be the  
propagation of rogue trust anchors which might be hard to identify  
operationally.

I have doubts that there is *any* general, in-protocol mechanism for  
this problem to be solved. It seems possible to me that the right  
answer may be that individual validators need to implement their own  
out-of-band mechanisms for acquiring an initial trust anchor, e.g.  
using existing software update mechanisms and other cryptographic  
means of establishing trust (e.g. TLS/X.509).

If I was to sum up my concern in one sentence, it would be "if you can  
trust old keys sufficiently to use them to find a trust anchor, you  
don't need to roll them in the first place".

Joe

---

From: Todd Glassey <[email-masked]>
Date: Tue, 25 Aug 2009 07:53:13 -0700

> don't need to roll them in the first place".
Joe - the question becomes one of the integrity of the records process 
and what provides some sense of non-repudiation in the operations of the 
trust model. Remember the Envelope of Trust (that's the accompanying 
term to "Trust Anchor") is what has to be maintained and that's key.

That said there are all kinds of PKI Operations Practice reasons 
including "its part of our policy to roll keys periodically" so it is 
appropriate that this was available. It might also be cool to create a 
historical entry somewhere as to why and to allow down-wind client's of 
this type of anchor to decide whether they want to trust that roll or 
continue using the existing cached images instead of updating.

I bring this up because a hacking of the trust-anchor is a reality that 
DNS hierarchies are going to be forced to deal with. That means that 
RELYING PARTIES (i.e. DNS servers which reference those trust-anchored 
sources) need to be able to from a policy control standpoint - decide 
whether they update or trigger an alarm to the local DNS Master.

Todd Glassey CISM CIFI
>
>
> Joe
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.65/2324 - Release Date: 08/24/09 12:55:00
>
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Aug 2009 11:07:17 -0400

> Joe - the question becomes one of the integrity of the records process

Yes, that's my point.

> including "its part of our policy to roll keys periodically"

If there's no practical motivation to roll keys, then let's not do it.  
Rolling keys is a pain.

If there *is* a practical motivation to roll keys, then let's not  
infer any trust at all from old keys.

Joe

---

From: Todd Glassey <[email-masked]>
Date: Tue, 25 Aug 2009 09:48:33 -0700

>> Joe - the question becomes one of the integrity of the records process
But your point is as a Systems Administrator rather than a Systems 
Auditor - the reasons for rolling the keys periodically pertain to 
Security Policy and the Practice which implements it.
> If there's no practical motivation to roll keys, then let's not do it. 
That's because of the design of the technical system - and if the policy 
controls specific to the use model had been designed before the protocol 
was implemented this wouldn't be so hard.
> infer any trust at all from old keys.
I agree that if a KEY is rolled it needs to have its application as a 
reliable TRUST ANCHOR revoked or terminated for events moving forward - 
but it still needs to be available for reviewing and re-certifying 
events from a forensic viewpoint. It *(the rolled key) still needs to be 
rolled so that requirement is still real.

Todd

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Aug 2009 12:53:01 -0400

On 25-Aug-2009, at 12:48, Todd Glassey wrote:

> I agree that if a KEY is rolled it needs to have its application as  
> a reliable TRUST ANCHOR revoked or terminated for events moving  
> forward - but it still needs to be available for reviewing and re- 
> certifying events from a forensic viewpoint. It *(the rolled key)  
> still needs to be rolled so that requirement is still real.

This is all very interesting speculation, but I'm not sure I  
understand how the use of old keys for forensic purposes relates to  
the problem of trying to establish a new trust anchor after a period  
of disconnection.

Joe

---

From: [email-masked]
Date: Tue, 25 Aug 2009 17:13:31 +0000

> infer any trust at all from old keys.

	please help me understand "practical motivation"?

--bill

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Aug 2009 13:37:32 -0400

> 	please help me understand "practical motivation"?

Which word is causing you trouble? :-)

Joe

---

From: [email-masked]
Date: Tue, 25 Aug 2009 17:51:30 +0000

> Which word is causing you trouble? :-)

	no...  but that is not germaine to this thread.

	the phrase, "practical motivation" is highly subjective.

	one might claim there is no practical motivation, since 
	key roll is so much of a "pain".   This is the type of 
	argument that claims we should plan for key "expiration"
	sometime after 2039.  make this a problem for our children.

	another claim for practical motivation is the knowledge that
	crypto is not static and whatever we use today will be breakable/broken
	in our lifetimes - so not having a proven/usable key roll process
	is worse than no crypto atall.  (the analogy of a datacenter w/ 
	a backup power system that is never checked/tested is too easy)

	i could argue that the motivation for either choice is clear but
	neither is practical ... 
	
	hence the highly subjective nature of practical motivation.
	who decides?  that mouse in your pocket?

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Aug 2009 14:10:41 -0400

> 	the phrase, "practical motivation" is highly subjective.

I agree, but I think that's ok.

> 	who decides?  that mouse in your pocket?

The person who manages the keys decides, I think. I'd guess for most  
people that means the zone administrator. My point is not really  
related to which way that decision goes, however.

Joe

---

From: Todd Glassey <[email-masked]>
Date: Tue, 25 Aug 2009 12:13:46 -0700

Joe Abley wrote:
>> reliable TRUST ANCHOR revoked or terminated for events moving forward 
>> - but it still needs to be available for reviewing and re-certifying 
>> events from a forensic viewpoint. It *(the rolled key) still needs to 
>> be rolled so that requirement is still real.
>

Joe  THIS IS NOT SPECULATION...  its preparing for Court which is what 
ALL log management is about - and that's not arguable. Therein we also 
see this  
http://www.latimes.com/news/nationworld/nation/la-na-crime-labs26-2009jul26,0,420958.story 
which is a unique story on how our work as technologists can easily be 
called into and challenged in Court's of law - specifically in criminal 
prosecutions.
 
Sorry - the Court's now allow the taking apart of the Wizard in Court to 
figure whether the Wizard is just another jerk-off or actually has some 
magic. So that changes the totality of the reporting models. That said - 
both things are critical - the managing of the change-log of the Key and 
the re-issuance process.

Todd

> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date: 08/25/09 06:08:00
>
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Aug 2009 15:17:12 -0400

On 25-Aug-2009, at 15:13, Todd Glassey wrote:

>> the problem of trying to establish a new trust anchor after a  
>> period of disconnection.
>
> Joe  THIS IS NOT SPECULATION... its preparing for Court [...]

Thank you for clearly framing your concerns.

Joe

---

From: Todd Glassey <[email-masked]>
Date: Tue, 25 Aug 2009 14:44:20 -0700

> Thank you for clearly framing your concerns.
You are welcome - and its time this standards process was focused on 
what we as technologists need to meet today's hurdles than in deploying 
technology which we try and hold the world hostage to force their 
acceptance of.

Todd Glassey

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 25 Aug 2009 14:52:53 -0400

> not to be trusted. Signatures made by a historical key are not to be 
There may be DNS resolver managers who would trust historical keys for 
sake of operational expeditiousness. Maybe the draft has such behavior 
as an implicit assumption.

> don't need to roll them in the first place".
That sentence applies to resolver behavior. As an authoritative IOT 
(Island of Trust) zone manager, you roll keys because you committed 
(more or less explicitly) to support those resolver managers having 
higher trust expectations.

I practice, the IOT manager announces a rollover policy, including an 
indication of which rollover announcement protocol is to be complied 
with as a commitment (including parameter settings as the case may be). 
In the case of DNSSEC trust anchors, old-key-signs-new-key is a sensible 
choice for some portion of DNS resolver managers, so the rollover policy 
should be a superset/refinement of this minimalistic resolver update 
strategy. The history draft would allow disconnected hosts to apply this 
minimalistic strategy retroactively.

I don't know to which extent you point towards revisiting the 
requirements in the trust anchor rollover area for DNS resolver managers 
who care more about trust continuity through automated rollovers. Your 
"out-of-band" idea achieves security, but "security by management 
exhaustion", i.e. push back the problem once more until the boss says 
"OK, let's do this, I need to rush to pick up my daughter at the baby 
sitter." It could be formalized as a long-lasting super-super trust 
anchor, but I doubt many security experts would put their name as the 
author of such a standard.

The two fundamental approaches to improve the long-lasting super-super 
trust anchor are RFC5011 (relaxes the "long-lasting" qualification) and 
TAKREM (uses long-lasting key material configuration that a) is consumed 
piece by piece as rollovers occur, and b) offer a greater challenge to 
cryptanalysis until each piece is consumed). But indeed neither 
completely solve the problem, as there is, inescapably, a catastrophic 
failure mode (apparent in RFC5011 when one works out the implementation 
options). But this seems off-topic until someone says otherwise.
> Joe
- Thierry Moreau

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 27 Aug 2009 16:32:58 +0200

Hi Joe,

In reply to your email, and the discussion following.

> e-mail before. I remember talking to people in Stockholm about it.

I'm sorry we missed talking.  Your email is clear, and well written.

> Keys are rolled for a reason. You can't always tell from the outside, as
> an automated device, what the reason was -- it could be that it's a
> executed within a particular time, or it could be due to a key compromise.

Given the discussion with Glassey, Manning and Moreau, I think I'll omit
discussion of key compromise causes.  Keys can be compromised, which
is enough, and zone operators can choose to either use the draft or not.

> A historical key has been replaced by a new one. A historical key is not
> to be trusted. Signatures made by a historical key are not to be trusted.

You have a good point here.  But trusted by whom and for what.

The effect of rollover and the trust history draft is that most people,
who are online reasonably often have the latest keys.  If you roll
at reasonable speed, say months or a year, then that is probably almost
everyone, lets call that number 99% here.

Some machines however have been offline, say half a year or two years,
and this 0.9% of people have the 'previous key'.

Then a long list of older and older machines, with older keys,
but also few of them.  And it ends with some lone geek who
still has an original copy of windows-9 or freebsd-9 :-).

So the rollover is clearly effective.  99% of people pick up that
new key within the timeframe, and 99.9% after 2 timeframes.
And with trust history, it works for the remaining 0.1% too.

Therefore, you get the benefits of rollover.  That means that
the old keys are phased out.  It is automated too.

> problem of how a validator which has been disconnected from the network
> for some period of time can bootstrap itself based on a trust anchor
> that was once good.

Yes that is the problem statement.

> It's not clear to me that using signatures from keys which are known not
> to be trusted is a good way for such validators to bootstrap themselves.
> In fact, I suggest that in general it's a bad way to do it, since in the
> event of key compromise the result could be the propagation of rogue
> trust anchors which might be hard to identify operationally.

Well after key compromise and subsequent 'software install', the entire
machine could be re-installed with something else... So, if the
mechanism is broken, then like any other security mechanism, the
machine is compromised.

> this problem to be solved. It seems possible to me that the right answer
> may be that individual validators need to implement their own
> out-of-band mechanisms for acquiring an initial trust anchor, e.g. using
> existing software update mechanisms and other cryptographic means of
> establishing trust (e.g. TLS/X.509).

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.

> don't need to roll them in the first place".

No.  Because the trust is by different persons.  Below I put us
in the position of each in turn.

The zone owner does not trust it enough, and wants roll over.
The zone owner knows that whatever lifetime it gives, it needs
to roll after that.  20 years later the number of bits may be
a little small, or there are better algorithms, ... and so on.
Therefore, the keys must roll.  Might as well every year,
that keeps staff and operations ready (like a fire drill).
Or perhaps there are advantages (less time to do that brute
force key cracking) to rolling regularly.  If he rolls
every year, and the key is cracked after 1year and a month,
then that attacker just missed 99% of the targets.  And has
trouble identifying the remaining 1% hiding amongst the rest.

Validator users of course, are usually in that 99%, and
have recent and secure keys.

For the other 1% of users, they only have this old key.
If the user knows the key is compromised via other means, well
we have the out-of-band channel done then.  Otherwise,
this algorithm gives the user every bit's worth of security
out of the old key.  And a leap of faith if the algorithm
is now weaker than rot13.

For many users, a leap of faith, only once per several
years, may be strong enough security.  In that case
the user would want to trust keys 'forever'.

Thus, "trust old keys sufficiently" means something different
for different people.

Does this alleviate your concerns, Joe?

Best regards,
   Wouter

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 28 Aug 2009 09:39:03 +0200

Hi Joe,

> the old keys are phased out.  It is automated too.

I think that is very important because I think especially for
important trust anchors, the trust anchor must roll over.
Also for the root.

On 08/28/2009 12:29 AM, Joe Abley wrote:
> 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?

(I understand you are saying Microsoft can use Windows Update ;
I am not saying what they have to do, the draft we are discussing
is how I propose to do it).

> I appreciate that a leap of faith can be a reasonable thing to make
> occasionally.

No, I said for specific persons.  You seem to latch on to that statement
as if everyone now has to do so.  This is not true.

If the zone owner says his keys are right for 4 years and you configure
an end date for those keys in 4 years then those people are not making
any leaps of faith.  They have full security.

> The mechanism you propose provides a means for an automated leap of
> faith, one which might be made without an end-user being explicitly made
> aware of it.

Well, if the user dares to make a leap of faith and configures his
software to do so, then he gets leaps of faith, right?

> My concern is that a compromised key might allow the linked list of
> historical keys to be compromised, which might have the effect of
> leading disconnected clients down a contrived path to a rogue trust
> anchor. If the trust-anchor mechanism is automated and implemented, then
> the effect might be that there is a large population of clients with
> naive users whose trust anchors could gradually become subverted with
> really no obvious way to measure it happening.

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.
Of course the draft already contains a mechanism to make such
attempts highly visible, did you consider those mechanisms?
(i.e. did you read that part; otherwise it may soothe you
considerably, as it makes attempts to subvert highly visible
and easy for measurement)

And we assume now that whatever attacker is working around those
mechanisms (and is thus some sort of powerful MitM, the ISP or so).
If the ISP wants to hide this act from measurement, then you
won't see it, right?

So with any compromised key the system can be subverted.
This is also the case with the 'one single key' that you propose
above.  If that is broken also all computers are going to be
subverted with no obvious way to measure whatever.

Of course, if someone does not have trust anchors that match the
current zone, then he cannot access anything, except stuff that is
fed to him by the MitM, right?  That would be obvious?

If the MitM seeks to just add one key of its own, then as soon
as the target manages to make a normal DNSKEY query (and sees
an updated root DNSKEY set, without the MitM key) he loses that
key again.  So we add a statement saying that if you see an
updated keyset, in the course of normal resolution, and this
keyset verifies, then this updated keyset MUST be stored on
stable storage?

So, what exactly are you afraid of, can you give more details?

And what would you like to measure happening?  How should this be
measurable?

I am sort of confused.  You seem to think that trust history must
somehow be invincible against compromised keys.  But that some other
mechanism, which relies on a single key kept for 20 years, does not
have to do so?

Also RFC5011 is vulnerable to a single compromised key, right?
This can be used to install an additional trust anchor that
even if the machine resumes normal operation stays 'dormant'
in the MISSING state?  Of course it takes 30 days to do so,
but that is why in the trust history lookup also a 30 day
wait period is installed.

Trust history lookup does have a lot of mechanisms in place to
provide additional protection (but not cryptographical) when a
key does get compromised.  This makes it more resistant against
compromise than the 'single key 20 years', but of course, once
that cryptographic key is broken, you get no more cryptographically
strong protection.

> The root zone is arguably the one for which accurate dissemination of
> the trust anchor is the most critical, since the security of the rest of
> the DNS for a single-anchored validator depends on it.

Yes, I agree, the root anchor is important.

> Your points about the applicability of this approach depending on the
> characteristics and security policy of the zone whose anchor is being
> published are well-made.
> 
> So perhaps I can modulate my initial concern to:
> - IoT operators should be aware of the risks of publishing using this
> approach that I outlined earlier, and balance those against the
> convenience of having an automated trust re-sync mechanism

So if operators say, I will publish trust anchors, roll them every
year, and say that after 5 years you can no longer trust them.
So if you use a key that is older than 5 years then you could
be really making leaps of faith.

Then everyone can configure their systems as to their perception
what security they want out of this?

The zone owner could even publish more detailed explanation
about how trustworthy keys of 1year old, 2 yrs old, and so on,
are.  And then people can pick their level of security.

You want to discuss 'why should a trust anchor perform rollover'?
I think trust anchors must roll over.

This mechanism gives the advantage that you can reduce the
exposure on older keys.  So it gives the zone owner a way
to distribute new trust anchors.  And most will pick it
up instantly.  And it does not 'disconnect' the older
ones.

> - I don't think this is a good idea for the root zone.

Well how do you suggest ex-offline validators pick up their
root key?

Is the root key going to be only for people who are online
every 30 days, so they can do rfc5011 ?

Best regards,
   Wouter

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 31 Aug 2009 11:33:05 +0200

Hi Joe,

On 08/30/2009 03:05 AM, Joe Abley wrote:
> 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.

>> [...]
> Yeah.
> 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.

> 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