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.
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 - 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 protected]
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
