[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [74.125.83.44]) 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 10.100.30.29 with SMTP id d29mr3755340and.247.1267854179703; Fri, 05 Mar 2010 21:42:59 -0800 (PST)
Date: Fri, 05 Mar 2010 21:42:59 -0800
Message-ID: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com>
From: Magnus Nyström <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. Comments: Abstract: - 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 3.1.1.3: - 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. Editorial: 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
- [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz