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

Eric Rescorla <> Mon, 28 July 2008 16:42 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 43FCC28C10C; Mon, 28 Jul 2008 09:42:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 422313A6829 for <>; Mon, 28 Jul 2008 09:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cxQ7ouk12FJq for <>; Mon, 28 Jul 2008 09:42:25 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 76AAF3A6915 for <>; Mon, 28 Jul 2008 09:42:25 -0700 (PDT)
Received: from kilo-2.local (localhost []) by (Postfix) with ESMTP id 8DD974B96B6; Mon, 28 Jul 2008 09:42:35 -0700 (PDT)
Date: Mon, 28 Jul 2008 09:42:35 -0700
From: Eric Rescorla <>
To: Adam Langley <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <>
Cc:, Joe Touch <>
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

At Mon, 28 Jul 2008 09:31:46 -0700,
Adam Langley wrote:
> 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;

Indeed, we should do so. If those algorithms in fact need a MAC they
should describe some procedure for generating and using them 
(and presumably attaching them to the message). AFAIK, neither
HMAC nor CBC-MAC requires such a nonce.

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

It depends what you mean by rekeying. If it involves a new protocol
exchange it is incredibly painful. If you mean just running the kdf
again, I agree that's fine.

tcpm mailing list