Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

Joe Touch <touch@ISI.EDU> Mon, 28 July 2008 14:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 74A8C3A6A49; Mon, 28 Jul 2008 07:28:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 315D63A6A1D for <>; Mon, 28 Jul 2008 07:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u0RDM8VSTQx9 for <>; Mon, 28 Jul 2008 07:28:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5789C3A69B9 for <>; Mon, 28 Jul 2008 07:28:53 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6SESjIh005899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 07:28:48 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jul 2008 07:28:13 -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] Review of draft-ietf-tcpm-tcp-auth-opt-01
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

Hi, Eric,

Eric Rescorla wrote:
| I did want to make one more note.
| At Sun, 27 Jul 2008 23:38:32 -0700,
| Joe Touch wrote:
|> | - The discussion of key rollover seems incomplete
|> |
|> |       >> TCP-AO implementations SHOULD change keys for a connection at
|> |       least every 2^31 bytes, to avoid resending segments with the same
|> |       TCP sequence number, data, and length under the same key.
|> |
|> | How is this intended to work?
|> The key management mechanism should react to sequence numbers rolling
|> over the ISN (perhaps masking out the high bit to roll over twice as
| Regardless of whether there is a KMP, it strikes me as unwise to punt this
| job to it.

There is a KMP; it is required (and we can't move forward to submit this
as final until there is).

| The TCP authentication protocol should be able to provide security for
| packets even in the face of sequence number rollover, out to the
| limits of security of the MAC algorithm (which far exceed 2^31 bytes
| in both cases). There are (at least) two potential approaches:
| 1. Use a (synthetic) extended sequence number.

We discussed this, but there are concerns with interactions with TCP. We
don't want to add separate, coordinated state outside the existing TCP
state mechanism.

| 2. Change the key used to compute the MAC inside the protoco.

Can you explain this?

| But I don't think it's a good idea to punt this to the KMP, since
| you don't really need to change the key for any cryptographic reason.

If there's no cryptographic reason, why would we need to change the key
at all? I.e., isn't the need for a unique per-packet nonce a
cryptographic requirement (if not, why do we care?)

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

tcpm mailing list