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

"Gregory M. Lebovitz" <gregory.ietf@gmail.com> Mon, 27 July 2009 08:24 UTC

Return-Path: <gregory.ietf@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41EF3A6BF8 for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 01:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0AoeXCaBPjM for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 01:24:30 -0700 (PDT)
Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id DEFFF3A69F5 for <tcpm@ietf.org>; Mon, 27 Jul 2009 01:24:30 -0700 (PDT)
Received: by pzk35 with SMTP id 35so175479pzk.32 for <tcpm@ietf.org>; Mon, 27 Jul 2009 01:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.115.55.17 with SMTP id h17mr9510433wak.58.1248683069057; Mon, 27 Jul 2009 01:24:29 -0700 (PDT)
Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id j15sm12953237waf.16.2009.07.27.01.24.26 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:24:28 -0700 (PDT)
Message-ID: <4a6d643c.0fba720a.10e1.ffffd732@mx.google.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 27 Jul 2009 01:24:21 -0700
To: Eric Rescorla <ekr@networkresonance.com>, tcpm@ietf.org
From: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
In-Reply-To: <20090726234651.18D7A50822@romeo.rtfm.com>
References: <20090726234651.18D7A50822@romeo.rtfm.com>
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-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2009 08:24:32 -0000

inline...

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 $
>
>TECHNICAL
>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
>as:
>
>            ( 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
>business.

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?



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

Done.



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




>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm