Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

<Paul.Koning@dell.com> Thu, 16 March 2017 20:19 UTC

Return-Path: <Paul.Koning@dell.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899A2129A4C for <ipsec@ietfa.amsl.com>; Thu, 16 Mar 2017 13:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.496
X-Spam-Level:
X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N_aqx5ZPFM1 for <ipsec@ietfa.amsl.com>; Thu, 16 Mar 2017 13:19:46 -0700 (PDT)
Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8921296A2 for <ipsec@ietf.org>; Thu, 16 Mar 2017 13:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1489695082; x=1521231082; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qOfdifl9luGqcYP3kQ74h7JEMYwCVdk6AhJdJrZbSc8=; b=IB6jKR9FlGRwT3nbiKGeCy74VLxZq53NsKh3v6zIIlmBm24rvoUxQfpZ s1maCyo0VaiEZtbEhMfdpP+yTgumyL+XQl2wUcFxW/TfWqRExumOl4IH3 a27ctnPEOgOwAuO72ZeU7o7E5lZHi8Ym8Nmaw119eVi7wayi2CC/JUXAm M=;
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 15:11:21 -0500
From: Paul.Koning@dell.com
Received: from ausxippc101.us.dell.com ([143.166.85.207]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 02:10:33 +0600
X-LoopCount0: from 10.175.216.249
X-IronPort-AV: E=Sophos;i="5.36,173,1486447200"; d="scan'208,217";a="922469200"
To: sheila.frankel@nist.gov
CC: david.waltermire@nist.gov, ipsec@ietf.org
Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)
Thread-Index: AQHSnfd0XQvvES+uGkGEDF04hrQ/d6GYB3wAgAAB9oCAADISAIAAAcoA
Date: Thu, 16 Mar 2017 20:19:40 +0000
Message-ID: <64AEC115-E33A-4E2C-9636-06AC33386F1E@dell.com>
References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <alpine.LRH.2.20.999.1703161300150.32675@bofh.nohats.ca> <MWHPR09MB144055428C1A1D147484C0BAF0260@MWHPR09MB1440.namprd09.prod.outlook.com> <DM5PR09MB1339A9DFAE3E6E09150BF627E7260@DM5PR09MB1339.namprd09.prod.outlook.com>
In-Reply-To: <DM5PR09MB1339A9DFAE3E6E09150BF627E7260@DM5PR09MB1339.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.178.128.191]
Content-Type: multipart/alternative; boundary="_000_64AEC115E33A4E2C963606AC33386F1Edellcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rrhl73tlMhUA7BlW81d5lcIN5q0>
Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 20:19:47 -0000

On Mar 16, 2017, at 4:13 PM, Frankel, Sheila E. (Fed) <sheila.frankel@nist.gov<mailto:sheila.frankel@nist.gov>> wrote:


Hi Dave,

I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonder if it would help to clarify the reasoning behind it.

For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying.   ...

If "compromises" means that the security is slightly weakened, then this wording seems ok.  If it means that the cipher is readily broken if you do this bad thing, then the only valid text is "MUST NOT".

paul