Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01

"Gregory M. Lebovitz" <> Mon, 27 July 2009 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F41EF3A6BF8 for <>; Mon, 27 Jul 2009 01:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w0AoeXCaBPjM for <>; Mon, 27 Jul 2009 01:24:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DEFFF3A69F5 for <>; Mon, 27 Jul 2009 01:24:30 -0700 (PDT)
Received: by pzk35 with SMTP id 35so175479pzk.32 for <>; Mon, 27 Jul 2009 01:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=7Lbr3ZykVIORvinSNSWljLDdA8Ccx6J2ohWrCLdo9ME=; b=q1Dz1lgNMejyR/z4svmcDxKgjpwCUZ+mVHTGJDYe7Td2vW/zGTVW9XI9dd9cmiDDcm QBiJjMogKjJNIA5c5fxNEx6QbcDqcJ2IK+rzTecJTUvy0MLdZfgNrgW8Z9edLFrvJSRY DYOcV2RoigBhUFl26fAQZfnL1DLii9t6X6tPQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=MlZoljI2JGNHyI0H4KqyZSa7QZiqI/OpnF4qkmae3ep9RtaCsjwh8lRGX78ZLKe/jq YfHaDi5+7Wgz69qdQLHtMdydPROEf9ynPK3PXJReFOtjAFC+HXuzkv7HBcsMF/arG0k4 BOHR9tKoHTYzVtDs40Gdvy301e8AKvc3h6GPY=
Received: by with SMTP id h17mr9510433wak.58.1248683069057; Mon, 27 Jul 2009 01:24:29 -0700 (PDT)
Received: from ( []) by with ESMTPS id j15sm12953237waf.16.2009. (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:24:28 -0700 (PDT)
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 27 Jul 2009 01:24:21 -0700
To: Eric Rescorla <>,
From: "Gregory M. Lebovitz" <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: <>, <>
X-List-Received-Date: Mon, 27 Jul 2009 08:24:32 -0000


At 04:46 PM 7/26/2009, Eric Rescorla wrote:
>$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 
>2009/07/26 22:40:47 ekr Exp $
>S 3.1.
>This mixing of the KDF interface and the NIST 800-108 interface
>is extraordinarily confusing.

I'm not sure it's "mixing". Isn't one is a subset of the other? The 
KDF interface is an interface. The NIST thing is the actual 
concatenated construct which fulfills the Context.

>To recap:
>The input to the KDF requires:
>- Master Key
>- Context (i.e., the conn-data)

it's not just the Data_Block (updated lingo, per auth-opt-05). In 
order to follow SP800-180, the context is a few things concatenated, 
and Data_Block is one of the things.

>- Output length
>Now, as it happens, you're constructing your KDFs a la SP800-108,
>so you then use the relevant PRF with an input block constructed
>            ( i || Label || Context || Output_Length)
>But that is not a meaningful part of the interface to the KDF
>as far as AO is concerned. If you were (for instance) to define
>a new TLS PRF based KDF, you would not use i internally because
>the TLS PRF generates an arbitrary length string. Again, it's
>important to distinguish between the TCP-AO requirements and
>what this document happens to do.

I think this document is NOT just the generic interface - that's 
covered in auth-opt-05. This document reminds us of the generic 
interface, and then specifically defines how to do the SHA1 and 
AES-128 KDFs themselves. That's why we made it specific. Maybe I'm 
not understanding you?

>S 3.1.3.
>Wait, I don't remember agreeing to this. I'm happy to use these
>as labels in soem IANA registry, byt people's UI is not our

This is the years of IKE interop work which motivates this. 
Clarifying the UI representations to make it very easy on operators 
is a good thing. Others opinions on this UI guidance?

>S 2.2.
>    The security issues driving the migration from SHA-1 to SHA-256 for
>    digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately
>    render SHA-1 weak for this application of SHA-1 in HMAC mode.  The
>    security strength of SHA-1 HMACs should be sufficient for the
>    foreseeable future, especially given that the tags are truncated to
>    96 bits.  However, while it's clear that the attacks aren't practical
>    on SHA-1, these types of analysis are mounting and could potentially
>    pose a concern for HMAC forgery if they were significantly improved,
>    over time.  In anticipation of SHA-1's growing less dependable over
>    time, but given its wide deployment and current strength, it is a
>    "MUST" for TCP-AO today.  AES-128 CMAC is considered to be far
>    stronger algorithm, but may not yet have very wide implementation.
>    It is also a "MUST" to implement, in order to drive vendors toward
>    its use.
>This is simply not true. It's not at all clear that AES-128-CMAC is
>stronger than HMAC-SHA1, and I don't believe you could get anything
>like a consensus of cryptographers to say that it was. The
>MUST-MUST was taken on the basis of a WG hum. I'm fine with that,
>but this justification needs to be removed.

Since this is others' text, I'll let those others respond.

>S 2.3.
>        (1)  Key Derivation Functions (KDFs) which name a pseudorandom
>             function (PRF) and use a Master_Key and some connection-
>             specific Input with that PRF to produce Conn_Keys, the keys
>             suitable for authenticating and integrity checking
>             individual TCP segments.
>This is confusing. KDFs may or may not be constructed with PRFs.
>However, THESE KDFs are so constructed. If you're giong to have
>a document which applies to future KDFs, don't say PRF here.

it does say "which name", not "MUST name". Doesn't this cover your point?

>S 3.1.
>                       An octet of all zeros.  An optional data field
>                       used to indicate a separation of different
>                       variable length data fields.
>This is just dangling.


>    When invoked, a KDF runs a certain PRF, using the Master_Key as the
>    seed, and Input as the message input and produces a result of
>    Output_Length bits.  This result may then be used as a cryptographic
>    key for any algorithm which takes an Output_Length length key as its
>    seed.  A KDF MAY specify a maximum Output_Length parameter.
>Again, misplaced concreteness.
>Woah, I think my numbered list cut and paste here seems needs some
>major re-editing. It was intended for the mailing list, not for
>direct import into the document.

send text.

>S 3.1.1.
>It's a mistake to talk about "Output Length" as a property of the KDF.
>In principle, this KDF could generate any output length of your
>choice by using i=0, i=1, etc.. Why are you nailing it down?
>S 3.1.2.
>I strongly object to the use of this magic key string here.

discussed with Tim Polk. done. We're back to 0^128 as the key in -02.

>S 3.2.
>This whole Conn_Key(KDF) thing is confusing. What's it doing?

Honestly, I thought that was the notation you requested upon review 
of -00... I'll ping you offline.

I'm posting -02 now, because there was naming I needed to update to 
stay in sync with auth-opt-05 anyway.

Thx for the review,

>tcpm mailing list