[tcpm] Wes's edits on tcp-ao-crypto-02 (was: Re: closing WGLC for TCP-AO)

Gregory Lebovitz <gregory.ietf@gmail.com> Wed, 10 February 2010 08:14 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 7832A3A73B8 for <tcpm@core3.amsl.com>; Wed, 10 Feb 2010 00:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.392
X-Spam-Level:
X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 DJfRY3XkgF5Z for <tcpm@core3.amsl.com>; Wed, 10 Feb 2010 00:14:23 -0800 (PST)
Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9C4753A687C for <tcpm@ietf.org>; Wed, 10 Feb 2010 00:14:22 -0800 (PST)
Received: by bwz19 with SMTP id 19so1650449bwz.28 for <tcpm@ietf.org>; Wed, 10 Feb 2010 00:15:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=qDo14qNCP7TPbZSXat/0HpMV5OLJqKZbymcqgRJBLgo=; b=J87BeUwu3HltdmarVbYSnbrrMpxBTfHGP+rOCfQkg/sIpMa84A8WJBrrv6EOLGnDSy DBIuBZcXn+u+9uxbSnNqqEelGi9p2wuE8xDgPpIdGKGQgqFunukzrw/gBA9NyNrSBiVW cMtYpj09fCBzqpBTTtWUbWFXWxP8dUWWtvOAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VOxKyhHWEZq881Tu1dRYZtpWRI0uS7+p7cJk9ulvTs1gTcK/3AgNrYK+dgFk98cHKn ZQNSDV7V0pV+YzTU1taUnQYxAaWbE6Hcbf+PwDtPgChbqHtqRWjLstq43AqTbPgaU/Ro BeRS+gN96wNDzpJ9OZImTM/XdK/1pEiMz/zaU=
MIME-Version: 1.0
Received: by 10.204.49.88 with SMTP id u24mr743799bkf.44.1265789728313; Wed, 10 Feb 2010 00:15:28 -0800 (PST)
Date: Wed, 10 Feb 2010 00:15:28 -0800
Message-ID: <f1548841002100015h19cded23kc96f49abd2bfd5bb@mail.gmail.com>
From: Gregory Lebovitz <gregory.ietf@gmail.com>
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>, Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="000325556df21dd2d8047f3aa363"
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: [tcpm] Wes's edits on tcp-ao-crypto-02 (was: Re: closing WGLC for TCP-AO)
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: Wed, 10 Feb 2010 08:14:24 -0000

Comments line.

Joe, there is one in here for you, where we need to align our two docs. Pls
take a quick look below and let me know what you think.
Gregory

On Tue, Dec 1, 2009 at 1:42 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE
CORP] <wesley.m.eddy@nasa.gov> wrote:

--snip--

>
> On the AO crypto draft
> ======================
>
> 1) editorial, in abstract:
> "algorithm(s)" -> "algorithms" ?
>

done


>
> 2) editorial, in Section 1:
> "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]."
> ->
> "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]."
>

done

>
> 3) editorial, in Section 1:
> "two key derivations functions"
> ->
> "two key derivation functions"
>

done

>
> 4) editorial, in section 2.2:
> "Security Area Directors"
> ->
> "IETF Security Area Directors"
>

done


>
> 5) editorial/technical, in section 2.2:
> "especially given that the tags are truncated to 96 bits"
> ->
> "even though the tags are truncated to 96 bits"
> ???
>

"especially" is correct. The point is that the SHA-1 output is longer than
96 bits, so it is saying that it is far more than even what is needed.


> 6) editorial/technical, in section 2.2:
> "aren't practical on SHA-1"
> ->
> "aren't practical on HMAC-SHA-1"
> ???
>

SHA-1 is fine here, because we are talking about comparison to the whole
family, not simply its HMAC usage.



>
> 7) editorial, section 7.1:
>

I think you mean 3.2 of the -crypto doc, and 7.1 of the auth-opt doc, yeah?


> use of Output_Length included here is not consistent with
> the way that the main auth-opt draft defines this.
>

>From auth-opt-10, sect 7.1, it uses "Output" as the MAC result itself. Then
below that it explains that "output-length" is different than "Output",
that:

"the output length, so no separate output length parameter is required. This
is specified as described in
[Le09<http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-10#ref-Le09>
]. "

Having said that, I agree that using "Output" is confusing, because in
auth-opt 7.1, "OUTPUT: MAC" and in tcp-ao-crypto sect 3.2 "Output" is an
element of the definition of each MAC_alg's usage, specifically "Output: The
final length of the bits used in the TCP-AO MAC field. This value may be a
truncation of the MAC function's original output length."

Proposed resolution (1):
change auth-opt document, replace "Output" with "Result" in 7.1

another possible resolution (2) is to change -ao-crypto doc, sect 3.2, as
follows:  s/Output/MAC_Length/

I think (1) is more clear, because in -ao-crypto we use "Output_Length" to
mean the KDF key output length, and it is an agrument to the interface of
the algo, so that the counter knows if it needs to run more than once. EKR
and I talked about this at length and think it best not to mix these two
things up. Yet I hat to ask Joe to rev -auth-opt again just for this, so I
could do (2) instead.

 Does that work for you, Joe?

I'll rev my doc with (2) above, so we can get it out tonight. If people have
issue, we can change it back during the next round of AD reviews.


> 8) editorial, section 3.1.1:
> "Each"
> ->
> ""
>

done


>
> 9) editorial, figure 1:
> formatting of top line is off
>
> done

Thanks again for the feedback,
Gregory.

>
> --
> Wes Eddy
> MTI Systems
>
>
>


-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks