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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
  Eric Rescorla wrote:
...
|> 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
...
| 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?

Point taken. So then it's between A/B1 and B2.

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

It depends on whether that precomputation is impacted by the use of ISNs
in the MAC; that's the only reason there's an A/B1 vs. B2 difference
noted above. How we specify the computation may affect whether it can be
precomputed or needs storage/recomputation.

We can jump up to the level of specifying the computation only (which
allows implementation flexibility), but we need to know (AFAICT) the
impact on these optimizations and whether we care...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiRfc8ACgkQE5f5cImnZruQXQCgrYHBO1g2LMIWMOpbUlqRD4bJ
l8QAnA5UL8U4z16q/tpu5VxMt0hSue1e
=tnZ4
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm