IETF Logo Mail Archive

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

<Paul.Koning@dell.com> Thu, 23 March 2017 13:04 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 A89F81296EF; Thu, 23 Mar 2017 06:04:52 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=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 bhi7MHljltSq; Thu, 23 Mar 2017 06:04:51 -0700 (PDT)
Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 06FED1293F8; Thu, 23 Mar 2017 06:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490274243; x=1521810243; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ks5J5TNMEYaivjyHcjMQD6auzDc7GKsDvgGtUpqOfNE=; b=rd5Js55gX2xxtYuxWrbn4QgDTHvbQFOF6JD2KCUlOf9/zF//XsN1hWgL gTIl3eK6HMGrpTaKnxIVxWHpcJZrZLM4hwci8xVsqhDuYK0B2Oe9PFmI0 GSraD/RDnfTORwgddMQa2Jq5PbiFLk/yyZ4boZH30bcod2tqsN5dGP2p5 8=;
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 08:04:03 -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; 23 Mar 2017 19:02:49 +0600
X-LoopCount0: from 10.175.216.250
X-IronPort-AV: E=Sophos;i="5.36,209,1486447200"; d="scan'208";a="925050817"
To: kivinen@iki.fi
CC: paul@nohats.ca, draft-ietf-ipsecme-rfc7321bis@ietf.org, ben@nostrum.com, ipsecme-chairs@ietf.org, ipsec@ietf.org, iesg@ietf.org, david.waltermire@nist.gov
Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)
Thread-Index: AQHSnfd0XQvvES+uGkGEDF04hrQ/d6GYB3wAgAqCfwCAADo4AA==
Date: Thu, 23 Mar 2017 13:04:47 +0000
Message-ID: <F28C3A8C-4811-430C-BABE-4AD1D782E6D9@dell.com>
References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <alpine.LRH.2.20.999.1703161300150.32675@bofh.nohats.ca> <22739.38728.808538.27709@fireball.acr.fi>
In-Reply-To: <22739.38728.808538.27709@fireball.acr.fi>
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: text/plain; charset="us-ascii"
Content-ID: <EE91D9B423219649A15C5F8917F4FF17@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/zT9iCb2k9L4Ja-0nErDE0w-NX_E>
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, 23 Mar 2017 13:04:53 -0000

> On Mar 23, 2017, at 5:37 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> Paul Wouters writes:
>>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
>>> used...". But the section goes on to say if you do it anyway, you MUST
>>> NOT use certain cryptosuites. So, does "... is not to be used..." mean
>>> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
>>> sort of requirements?
>> 
>> It is indeed. I think a SHOULD NOT would actually be appropriate ?
> 
> We do not want to make the implementation of the manual keying MUST
> NOT, as it is still useful in testing and similar situations, but we
> do not want anybody using it in any real world use cases. As this
> document is mostly about the implementation and tries to stay out from
> the issues about what should be used (as explained in the 2nd
> paragraph of the section 1.3).

The problem is that currently USGv6 mandates support for manual keying based on earlier RFC text.  I wonder if the proposed text is strong enough to make them understand this is wrong.  This is why I was pushing for MUST NOT.

Exotic test scenarios aren't all that good an argument, for those you can hack the code and ignore the RFC.

	paul

v2.23.0 | Report a Bug | By Email