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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id ABC7A3A6B11; Thu, 31 Jul 2008 02:04:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82AC13A6B0D for <>; Thu, 31 Jul 2008 02:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V3a0CTnjbatd for <>; Thu, 31 Jul 2008 02:04:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A3B6F3A6B08 for <>; Thu, 31 Jul 2008 02:04:15 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6V944oY020541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 02:04:07 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Jul 2008 02:03:21 -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 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...

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

tcpm mailing list