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

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

Question to the WG:

	- is the WG comfortable selecting and fixing a mechanism
	for using the ISNs for key uniqueness inside TCP-AO,
	or would it prefer to push this to the KMS?
		(my impression is that keeping this inside TCP-AO
		seems to be preferable, please speak up if otherwise)

	- which of the above mechanisms is preferable?
	i.e., A, B1, or B2

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

iEYEARECAAYFAkiRd90ACgkQE5f5cImnZrtwHgCdHF1cUrpIPcW3SzUbj0CxIzqz
08QAoKvbVPfM45a2zXXj6xSjikG3oxU0
=13gk
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm