[secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-02

Magnus Nyström <magnusn@gmail.com> Sat, 06 March 2010 05:43 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2717428C15A; Fri, 5 Mar 2010 21:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5lRfkETsvzvU; Fri, 5 Mar 2010 21:43:00 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 2B58E28C126; Fri, 5 Mar 2010 21:43:00 -0800 (PST)
Received: by gwb10 with SMTP id 10so2387401gwb.31 for <multiple recipients>; Fri, 05 Mar 2010 21:42:59 -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:content-type; bh=lHs1gUxbVk9/lxzSe7OyTSOJIm7Qm4qT2qvauwG9cGg=; b=C/d20H9D099i5Z5DITJq2IrDQznOPBvOM84KMWseBe9SCcLm4c75ThvEkkJQxJmRDK XKk9d11UDBdWDV0NNxFXfi9gTsLnYv4vIQq7o5GPVf2p+dp/FjMSTKBYmRHTHkgoKTGV 60wvJ+K1U1gng2+G/5vYBbPHMQvtJRzSW5Dn0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MWKd3sx04K4T4CHtvVa+HvnnAqMM1XfY8nMhfTrpjYrxn3IEJ+D9XkYldsy2AXMgcE 821naSb+9/v5gCBxLxxCV06QG2obn1YyvnIWIEwhqnIIeTe7y/nCwTiNMp2LP0nyDo/U knZ6hKEZf0mziQqhaaGljc/BRsQxkuthLW5kY=
MIME-Version: 1.0
Received: by with SMTP id d29mr3755340and.247.1267854179703; Fri, 05 Mar 2010 21:42:59 -0800 (PST)
Date: Fri, 5 Mar 2010 21:42:59 -0800
Message-ID: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, gregory.ietf@gmail.com, ekr@rtfm.com, magnus.westerlund@ericsson.com, lars.eggert@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2010 05:43:01 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments

This document specifies requirements on cryptographic algorithms to be
used in the TCP Authentication Option (TCP APO). It also specifies
some mandatory algorithms.



- The abstract does not mention that the document also specifies
requirements on future algorithms. IMO, it should.

Section 1:
(- Last paragraph is what prompted my comment on the abstract.)

Section 2.2:

- Suggest moving the note explaining the need to mandate two MAC
algorithms to the Security Considerations section as it does not
contain normative text but does contain security considerations.

- Section

- It is a little surprising to see that the SHA-1-based MAC algorithm
is selected as the default one, given that this is a new specification
and the industry is moving away from SHA-1. C.f. the work on XML
Encryption 1.1 and XML Signature 1.1 that specificallly recommends
against use of SHA-1 in new applications.

- Section 6 (Security Considerations):

In the fourth paragraph, there is a discussion around the fact that
the document does not force use of a 16 octet key. I think it would be
useful to at least clearly state a recommended minimum key size.


Section 1:

- "between to endpoints" - "between two endpoints"?

Section 3.1.1:

- "fixed-length output lengths" -> "fixed-length output"?

Section 3.2.1:

- "will be that has" -> "will be that"?

-- Magnus