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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 660D83A6895; Mon, 28 Jul 2008 07:26:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 339DF3A69EB for <>; Mon, 28 Jul 2008 07:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZjSVqK6C55Ke for <>; Mon, 28 Jul 2008 07:25:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4CDB3A6895 for <>; Mon, 28 Jul 2008 07:25:56 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6SEPdiw004717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 07:25:42 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jul 2008 07:25:08 -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:
| At Sun, 27 Jul 2008 23:38:32 -0700,
| Joe Touch wrote:
|> Hash: SHA1
|> Hi, Eric (et al.),
|> We'll have time to discuss these issues in detail later today at the
|> TCPM meeting. Here is some potential context for that...
| I'm not in Dublin.

We can continue on the list in that case...

|> Eric Rescorla wrote:
|> | $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr
|> Exp $
|> |
|> | I've reviewed the latest version of this document and while it
|> | seems to incorporate some improvements over the -00 version,
|> | I still have a number of concerns:
|> |
|> | - The document seems to assume an (unspecified) external key management
|> | mechanism. That seems less than maximally useful
|> The split of this work into separate key management and TCP extension
|> documents was a prerequisite to the design team's output. The WG chairs
|> and/or ADs can speak to it more directly.
| That may be so, but it seems to me that it's unwise regardless.  As I
| indicated in PHL, this protocol as it stands isn't really useful in
| the absence of a key management protocol.  Since no such protocol
| appears to be on the horizon... With that in mind, I've elided the
| detailed comments below relative to that.

My understanding is that this document will not move forward without a
companion keying document. Let's assume that and press on...

|> | S 1.1.
|> | I don't see a lot of value in pre-specifying two MAC algorithms
|> | as MTI. There's no reason to believe one isn't plenty, as used
|> | in other protocols.
|> The need for two required algorithms mirrors the intent of RFC4305's
|> "SHOULD+", which requires one, but suggests that two algs may be
|> required in the future. The design team suggested that requiring two
|> algorithms now would be prudent, notably so that if one were compromised
|> (either entirely, or effectively weakened due to computational
|> exploits), the other would be pre-deployed. The two could also trade
|> strength for performance, depending on which algorithms are recommended
|> by SAAG.
| Yes, as I've now said several times, this strikes me as massive
| overkill. If SHA-1 is ever weakened to the point where HMAC-SHA1
| is implicated, we'll have problems far, far, more serious than
| the occasional attack on TCP AO.

It's trivial to resolve this via WG feedback and SAAG input. If one is
sufficient, so be it.

|> | S 2.2.
|> | Figure 2 is kind of hard to read since the length of the kind
|> | field is 16 bits, but kinds are 8 bits, rigth?
|> The length of the field is wide due to the text; that will be fixed to
|> be proportional to the bit width (8 bits, as you note).
|> | S 3.
|> |                >> At least one direction (inbound/outbound) SHOULD have
|> |                a non-NONE MAC in practice, but this MUST NOT be
|> |                required by an implementation.
|> |
|> | 1. This seems like a bad idea. It's very hard to analyze the security
|> | properties of a connection when only one side is protected. To take
|> | one case that is obviously bad, if you're worried about DoS attacks
|> | and you use TCP-AO, then forging packets in either direction can
|> | bring it down. I would reverse this and require MACs in both
|> |
|> | 2. Even if we stipulate that this might be an OK idea, it's not
|> | appropriate to require implementations to support it.
|> We discussed the utility of asymmetry in Philadelphia last March. The
|> point is to require implementations to allow the user to request
|> connections configured this way; we can add that connections MUST
|> default to using a real MAC in both directions by default. Does that
|> address your concern?
| Well, as I recall, you asserted it the value of it and I disagreed.

I asserted the value of keeping it in for potential future use.

| As I recall, the example you offered was the one-way authentication in
| TLS, which is really not that apropos, since it only applies to the
| key management protocol, not to the data, which is authenticated in
| both directions.

We discussed that in Phila. I recall that we agreed that this wasn't
exactly like TLS. However, I preferred leaving it in for future use.

| Perhaps you could restate your rationale for this?

About 10 minutes into that future ;-), we were discussing (as I recall)
channel binding and connection latching, at which point someone (?)
suggested TCP-AO could start in NULL in one direction, and escalate via
enabling a new KeyID (and thus configuration) via in-band exchange. I
recall your noting that this was a good reason for asymmetry.

We could update the doc to include that rationale...

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

tcpm mailing list