Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

"Adam Langley" <> Mon, 21 July 2008 19:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 0E2E13A6867; Mon, 21 Jul 2008 12:43:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA68C3A6867 for <>; Mon, 21 Jul 2008 12:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tcqA7ebeNkCa for <>; Mon, 21 Jul 2008 12:43:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC1163A67DD for <>; Mon, 21 Jul 2008 12:43:22 -0700 (PDT)
Received: by with SMTP id b25so1215445rvf.49 for <>; Mon, 21 Jul 2008 12:43:58 -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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KHBAczIDvNp1Ojkfich6CWHEogK/G4/VgZlFerTyVWk=; b=bPLdF49vpnDr/KZV0Xr+odhsw3Uj4NNLoeq1SSLQ5Gv+RYUm3Y1eM1NCw7GSPhe8TQ iNneVcq09Hxo+HeDwsZB7XnR/Z+i0lcfiDGSJK/RGKh3lXyt5XvIZg5q6Vr3hzLXovuF FqjLjijiTPJOKNl6l7GEzqNe8W6Dna8cOTd50=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=dooz6VV+qQmEgKhDxsbM1AxPl9rX1QkgLOI//2BWFCflifjZUoztS/d3kKKtEdB/f1 L21/n86uTp0KuYjOOfRudHOa0r5dpzUn8iHRwz8EY3U4F9g5gHgYtcyAhLTC0Ein5ZY2 Jdn90XsUfHZqGq8ZcGI3RuNWur9gM7rBa4cOU=
Received: by with SMTP id m3mr2065468rvd.38.1216669438108; Mon, 21 Jul 2008 12:43:58 -0700 (PDT)
Received: by with HTTP; Mon, 21 Jul 2008 12:43:58 -0700 (PDT)
Message-ID: <>
Date: Mon, 21 Jul 2008 12:43:58 -0700
From: Adam Langley <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <>
X-Google-Sender-Auth: b4d9b71577e0b610
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt
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

2008/7/14  <>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>        Title           : The TCP Authentication Option
>        Author(s)       : J. Touch, et al.
>        Filename        : draft-ietf-tcpm-tcp-auth-opt-01.txt

An item which I believe is unclear in the spec:

Are KeyIDs specific to a single direction? E.g if A and B are
transmitting with different keys, could they both call them KeyID 0?
At the moment the wording around the TSAD seems to allow this
(specifically 6.1).

Also, comments on the linux netdev mailing list got me thinking more
about key rotation and I think the spec probably needs a sentence or
two advising about the use of key rotation.

The spec currently suggests that rotation occur every 2**31 bytes
sent. It's not clear if the keys for each direction are assumed to
rotate independently or not.

If the directions are independent then a large one-way transfer allows
an attacker to build up a dictionary of valid ACKs. Since the transfer
is only one way, the ACKing side will never rotate keys. Thus an
attacker could step in and convince the sender that everything was
fine even if the true destination was dead.

If the keys rotate after 2**31 bytes sent or recved there is a
possible window issue. Consider a host which is sending with a very
large window over a high delay link. It transmits several key
rotations worth of data before the first ack comes back from the other
side. Since this ack was elicited by the beginning of the data, it
will be transmitted with the first key. If the first key is still
active, everything is fine, but if the key window has rotated to the
point where old keys are getting evicted then the ACK will be

This currently shouldn't be a problem because the max window size is
1GB, which is less than 2**31 bytes. At some point in the future, if
window scaling is allowed to grow past 2**14, then key rotation could
limit the window size.

Given all these questions, I think the spec should make some advisory remarks.

I'm not too sure, but I think I like rotating a per-direction key
better. The ACK dictionary attack is unfortunate, but if we aren't
having real sequence numbers then our security is limited at best
anyway. Based on that I'd suggest a 2-key pair, where, for a
half-connection from A to B: B RX enables key 1 at 2**30 bytes
received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0
at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That
would also mean that KeyIDs are specific to a given half-connection.


Adam Langley
tcpm mailing list