[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Noel,
On Jan 17, 2008, at 6:08 AM, Noel Chiappa wrote:
Well, I'm not so sure. I'm not a crypto math expert, but...
Neither am I, but...
AFAIK, this isn't an issue with public-private encryption, so I
don't see a
need to do periodic key rollover. (If I'm wrong about any of the
crypto
aspects of all this, someone please enlighten me! :-)
My understanding is that you need to periodically replace keys in
order to thwart brute force attacks (among other reasons). RFC 4641
discusses this in the context of DNSSEC in section 3.3.
And how much 'touching' of the trust hierarchy you want to impose on
the lookup agents.
Sorry, didn't follow that - can you expand a bit?
Typically, the lookup agents will need to have the trust anchors
configured by some means (usually, manually). If you have multiple
trust anchors, you'll need to reconfigure those trust anchors in the
lookup agents every time there is a change. In RFC 4641, the
recommended period for key rollover is 12 months. If you're
partitioning the namespace into 256 pieces, this implies making (at
least) 256 changes to the configuration of each lookup agent you are
responsible for per year where one implication of doing it wrong is to
completely disable routing of systems dependent on that lookup agent
for some or all of the partitions of the namespace.
while only having 2 things to break when you configure your lookup
agent...
I don't expect people to be typing the master keys in! Yes, they
would be
distributed out-of-band ("printed in the newspaper", one wag
suggested), but
I was assuming they would more be included in software distributions
as a
file.
This puts much trust in the software distribution mechanism (chicken-
or-egg problems may lie here). In the case of DNSSEC, this turns out
to be a non-trivial problem. This may be because of the
idiosyncrasies of the DNS (e.g., distributed authority) and may not be
applicable to what we're discussing here, however one of the lessons
DNSSEC has taught me (over the 10+ years I've been involved in it,
either directly or on the periphery): ignoring operational key
management requirements can render whatever you come up with
completely useless. FWIW.
Regards,
-drc
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg