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

Joe Touch <touch@ISI.EDU> Thu, 31 July 2008 08:30 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4ADFE3A68C0; Thu, 31 Jul 2008 01:30:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5A753A6780 for <>; Thu, 31 Jul 2008 01:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.19
X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sUUdnXqRRX7L for <>; Thu, 31 Jul 2008 01:30:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F64E3A68AE for <>; Thu, 31 Jul 2008 01:30:36 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6V8TqYS006198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 01:30:00 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Jul 2008 01:29:17 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list