Re: [tcpm] TCP-AO: Text for New_Key Process

[Eric Rescorla <[e-mail]>]

At Tue, 03 Feb 2009 08:57:04 -0800,
Joe Touch wrote:
> 
> Eric Rescorla wrote:
> > At Tue, 03 Feb 2009 08:34:53 -0800,
> >> OK, let's call the place where the connection info is stored the STORE.
> >>
> >> Then the steps still become:
> >>
> >> - - get the keyID from the packet
> >> - - go to the STORE to find out how long the MAC is
> >> - - pass the keyID and (optionstart + len - maclen)
> >>
> >> Still three steps, vs one:
> >>
> >> - - pass the keyID and (optionstart + 2)
> >>
> >> Note that the second way doesn't need to go to a separate table of
> >> information to figure out how to finish parsing the packet. Regardless
> >> of what you call it or where you put it, this takes multiple steps and
> >> consulting the STORE before you can pass the required information to the
> >> verification algorithm.
> > 
> > Again, I wouldn't construct the system this way.
> > 
> > Rather, you hang the information required to process each connection
> > off the connection itself. This is how pretty much every SSL/TLS stack
> > works.
> 
> I don't think you're seeing the extra work;

You're right, I'm not.


> you're focusing too much on
> the assumption that the STORE is in a single place. OK, so let's call
> the place where the properties of a connection are in TCB++ (note that
> the TSAD isn't the place you go for every packet; you can easily keep
> connection info in the TCB++, and an implementation probably will, and
> we already note that in the ID).
> 
> So the steps are still:
> 
> - - get the keyID from the packet
> - - check the TCB++ to figure out where the MAC is
> - - pass the keyID and (optionstart + len - maclen) to the algorithm
>
> The point is that you can't parse the option without extra info that is
> stored elsewhere - i.e., not in the packet. Whether it's central or in
> the TCB++ is not the point.

And again, so what? You can't *verify* the option without having the
key that corresponds to the key-id. The problem here is that you're
assuming an odd encapsulation boundary, namely:


> - - pass the keyID and (optionstart + len - maclen) to the algorithm

But this is not how I would build things, because it's more helpful to
have the key-id->MAC mapping in a common place rather, I would do this:

1. Get the key-id from the packet.
2. Look up the key-id in XXX to get the relevant algorithm info, namely:
   - algorithm 
   - key
   - MAC length
3. Pass (key, <MAC input>) to the MAC function.
4. Compare the result to the MAC

With this design, it's trivial to add a step 2(b):

2(b): strip off the extra key-ids.


That said, I consider this discussion basically irrelevant: the right
question is whether it's important for this protocol to offer some
automatic mechanism for key switchover [and no, I don't think your
mechanism qualifies because it requires some external intervention
either from users or from some (nonexistent) key management system].
If the answer is yes, then we need to figure out what the best way
to do that is [and as it happens, I'm not that enamored of this
approach.] Certainly implementation complexity factors into what
the best way to do it is, but given the scale of complexity we're
talking about, I don't think it's a meaningful consideration for
whether we should add this type of functionality at all.

-Ekr


_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm