Joe Abley wrote:
On 21-Aug-2009, at 10:08, W.C.A. Wijngaards wrote:
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 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.
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.
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".
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
