Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: David Conrad <drc@virtualized.org>

    >> there is no single entity which signs bindings for the entire
    >> namespace - as I mentioned, we would probably want to split the
    >> namespace up into zones (e.g. maybe /8's), and have a separate key
    >> (and signing entity) for each zone, in part so that no single break-in
    >> can compromise (and require re-signing of) bindings across the entire
    >> nameapace.

    > Isn't the implication of this a need to rollover multiple keys ... that
    > is, instead of having 1 trust anchor that you periodically rollover,
    > you have 256? (I'm assuming you would need to rollover keys as a normal
    > part of security hygiene).

Well, I'm not so sure. I'm not a crypto math expert, but... my understanding
was that systems which generate new keys periodically (such as WPA) do so
because in the particular encryptions systems they use, if you have enough
encrypted text, it increases the chances you can find the key. So, they
change their keys on a regular basis.

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! :-)


    >> it's really a question of how much configuration overhead one wishes
    >> to incur, versus the amount of flexibility in terms of distributing
    >> that 'power'.

    > 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? I would have assumed that
there's no extra overhead in the lookup agents (unless they want to be
paranoid and check out that *all* the signatures are valid). And course
there's no extra network traffic at the lookup agents because the whole point
of this scheme is to have *no* network traffic at a lookup agent to check the
signature on a binding!


    >> So, let me know what you think about the 'multiple independent signing
    >> authorities' concept as a way to deal with the sole (per zone) [signing
    >> authority] issue you raised

    > What are your thoughts on multiple independent signing authorities,
    > with each authority signing the bindings for the entire namespace?
    > ... then you could cross validate (if necessary... sort of like getting
    > a second opinion if validation fails)

The rationale behind splitting the namespace up into zones, and signing each
zone independently, was to i) limit the damage if there is a security breach,
and ii) limit the number of bindings which have to be resigned if there's a
security breach. Having multiple signing authorities (whether it's per-zone,
or for the entire namespace) is really orthagonal to that, multiple signers is
more a "limit the power" kind of thing.

The sole exception is that if you had *more* than two, you could do a
"majority votes" kind of thing to limit the results of a security breach...
but what if you get in a binding that only has one signature? Is it valid, or
the result of a security breach? So I guess the answer is that if a binding is
only valid if it has M valid signatures (where M >> 1, and somewhat less than
the total number of signing authorities), then I suppose you could get goal i)
out of a single large zone with multiple signing authorities - whilst not
giving any one signing authority too much leverage.

I don't really have any axe at all to grind on i) how many zones the system
has, or ii) how many signing authorities we have. Whatever answers people
think will provide the best cost/benefit results are fine with me.


    > 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. I mean, nobody's going to type in a 1024-bit (or longer) key! So
whether it's 2, 256, or 768, would it really matter that much?

	Noel

--
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