Re: [tcpm] tcp-auth-opt issue: unique connection keys

[Eric Rescorla <[e-mail]>]

At Thu, 31 Jul 2008 01:29:17 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> |> The difference between #1 and #2 is that #2 overwrites the TSAD entries
> |> with the hash. Yes, the issue with simultaneous opens is the need for
> |> multiple keys per "host/port quartet" (can we call that a socket pair,
> |> as per 793?).
> |>
> |> <individual hat on>
> |> We could also keep multiple keys just in case there's a simultaneous
> |> open, until at least the SYN-ACK is received on a given side (at which
> |> point we can drop the extra keys).
> |>
> |> E.g.:
> |> 	origkey = as installed by KMS
> |> 	SYNkey = hash(origkey, src_ISN) computed when SYN is sent
> |> 		before an incoming SYN is rec'd (by either side)
> |> 	connkey = hash(origkey, src_ISN, dst_ISN)
> |> 		computed when the ack of the SYN is rec'd or
> |> 		an incoming SYN is ack'd
> |>
> |> only the connkey can overwrite the origkey in the TSAD. for space
> |> reasons, we don't want to keep too many keys around.
> |
> | This seems like unnecessary concreteness about the implementation.
> | The question isn't what's stored in the database but rather what
> | keys are used to protect the packets. Given that at least in the
> | manual key management mode the "origkey" is going to sit around
> | for years, it's a little weird to talk about it being "replaced".
> 
> There is state in a few different places:
> 
> 	KMS keys, which could persist for years in the static case
> 
> 	connection keys, which persist only during the connection
> 
> In the above example, the question is how many keys are kept for a
> single connection (i.e., is one stored and it overwritten, or are two
> kept, etc.), or whether they are computed on-the-fly for every packet
> that goes out.
> 
> |> If we prepend the ISNs to the data, we avoid separate calls to the MAC
> |> algorithm during the three-way handshake, but we keep reprocessing the
> |> ISNs for each packet sent.
> |
> | The performance advantage of either choice seem to be rather slight.
> |
> |> So at this point both #1 and #2 could support simultaneous opens. Which
> |> method is preferable and why?
> |
> | As I indicated in my previous comments, you could probably
> | cryptographically tolerate only one master MAC key and just use
> | differentiating prefixes rather than separate keys. Convention
> | is to use separate keys, though, in my experience, so this
> | probably requires less analysis.
> 
> The differences in the alternatives discussed so far:
> 
> A- precomputed keys
> 	require additional per-connection key storage space
> 
> B- on-the-fly
> 	1- if ISN is hashed into the key used for a packet,
> 	this requires an additional full MAC computation
> 	per packet
> 
> 	2- if ISN is prepended to the data, this requires
> 	a longer MAC computation
> 
> which of these is more efficient depends on:
> 	- saving computation vs. storage
> 	- the length of the connection
> 
> Overall, if this is encoded into TCP-AO, we need to encode (and fix as
> static) this choice. We could extend the TSAD API to outsource this
> issue, but (as Eric noted) this complicates the TSAD API.

I must be missing something. Our job is to specify what bits go
into the MAC. Why do we have to specify when these computations
are done beyond that? It seems like implementations should be
allowed to make whatever time/space tradeoffs they feel are
most appropriate. In particular, why should we require one of
A and B(1), since they produce the same data on the wire?

It's worth noting at this point that implementations of HMAC often
adopt the time/space tradeoff of precomputing the first round of HMAC
computations (to digest the keys) and using that instead of the key.
If you were working with prepending ISNs, you might also include
the ISNs in that state. When we talk about key storage, I would hope we aren't
precluding that sort of optimization.

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