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

"Adam Langley" <> Mon, 28 July 2008 16:31 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AB9423A6A03; Mon, 28 Jul 2008 09:31:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C26F83A6A03 for <>; Mon, 28 Jul 2008 09:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bmvhOMPQhpoY for <>; Mon, 28 Jul 2008 09:31:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 030853A69E4 for <>; Mon, 28 Jul 2008 09:31:35 -0700 (PDT)
Received: by with SMTP id b25so3727989rvf.49 for <>; Mon, 28 Jul 2008 09:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=X4pfFHZ4K3eqssa8DpG91XABdt7Y+p2YkkLau9MScZA=; b=OxKakTnJzvpaRU1N7v4pCaTzXwvgZR0hmFjlINaF/uUSKrggBSdULTz3PnDLrUcZ6t quZKs+qRCajgVfHLIRuX9KO3see6UR5M7DHLgKhQXO0rle7GJ1tK0Mj7Q7tBCxvWIhyN Xk4M6QE6crkbER2ZebqO7f2DaqqQhnNQLazHg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qM3I2uqmR2L27yMBW6Y0HqZR9Imnxim327Vj8FcnUV52+LnG/Pqemt3CUQPVws6m4y 6+hasc7X24N7Mz3nXp8WRGPy9CqVNn5QTQkKmy7mlHygRml+1S/BwqNSZuu1oaBpz6FX NffEl4t9yp+naP77w6IYuVgv1ne3FIqxhR5R4=
Received: by with SMTP id g21mr2461054rvj.248.1217262706152; Mon, 28 Jul 2008 09:31:46 -0700 (PDT)
Received: by with HTTP; Mon, 28 Jul 2008 09:31:46 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jul 2008 09:31:46 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <>
X-Google-Sender-Auth: d296c1165e78af7c
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Mon, Jul 28, 2008 at 8:05 AM, Joe Touch <> wrote:
> | There is no need for a unique per-packet nonce.
> If so, then why generate fresh keys on rollover?

(This is pretty much a reposting of a previous email, but people still
seem to be hazy on this point)

We have a couple of reasons for wanting to define an nonce:

Reason 1: Without a monotonic counter, a MAC is open to replay
attacks. I'm not sure how serious this is. Certainly you can elicit
different behaviour from stacks by replaying, say, an ACK very
quickly. This is undesirable, but it might be acceptable. More
troubling is the possibility of exploiting sequence number rollover to
inject a valid packet from 2^32 bytes in the past into the current
stream. A monotonic nonce would mean that we could reject replays.

Rotating the keys faster than the sequence number rolls over mitigates
the most grievous of these issues.

Reason 2: Modern dot-product and polynomial MAC functions require an
nonce as an input and their
security depends on the nonce never being reused for any other message
with the same key. Consider a connection where all the
application-level data transfer is one way and a packet, seq number n,
is lost by the network. Here, it's very possible that an ACK for n-1
is transmitted, followed by an ACK for n-1 with a SACK option. Now
we've transmitted two different messages with the same nonce. Any
nonce based only the sequence numbers has this problem unless we
disable/don't include SACK. Also, if we are only including 32-bits of
seq, then we trivially repeat every 2^32 bytes.

Now, we can just ignore the MAC functions described in reason 2;
having a per-message counter is probably too much additional work.
Having a "pseudo" extended sequence number is very little work
(really, I've already implemented it) and that mean that we don't have
to rekey faster than the 32-bit sequence rollover. However, the
rekeying isn't all that painful anyway.


Adam Langley
tcpm mailing list