Re: [IPsec] Issue #176: What to do with a proposal of NONE

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 08 March 2010 15:20 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51BA3A6A03 for <ipsec@core3.amsl.com>; Mon, 8 Mar 2010 07:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Level:
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 i5D8bPO0TvL8 for <ipsec@core3.amsl.com>; Mon, 8 Mar 2010 07:20:19 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 583633A69AE for <ipsec@ietf.org>; Mon, 8 Mar 2010 07:20:05 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o28FK7s8090103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 08:20:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240804c7bac6000ac6@[10.20.30.158]>
In-Reply-To: <19349.4958.130660.415650@fireball.kivinen.iki.fi>
References: <p06240811c7b8ad8a9912@[10.20.30.158]> <19349.4958.130660.415650@fireball.kivinen.iki.fi>
Date: Mon, 08 Mar 2010 07:20:06 -0800
To: Tero Kivinen <kivinen@iki.fi>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: IPsecme WG <ipsec@ietf.org>, Pasi Eronen <Pasi.Eronen@nokia.com>
Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Mar 2010 15:20:29 -0000

At 5:10 PM +0200 3/8/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/176>
>>
>> Pasi says:
>>
>> Section 3.3.6 says "If one of the proposals offered is for the
>> Diffie-Hellman group of NONE, the responder MUST ignore the
>> initiator's KE payload and omit the KE payload from the response."
>>
>> This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it.
>>
>> However, negotiation of DH groups and KE payload is already well
>> described in Sections 1.2 and 1.3 (paragraphs mentioning
>> INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is
>> completely redundant. Thus, I'd propose just deleting the whole
>> paragraph.
>>
>> Paul says:
>>
>> That whole paragraph has been there since -00. Only the last
>> sentence was added in -03 almost a year ago. It was added to fix
>> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/6>, but I can
>> easily believe that fix was not correct. However, sections 1.2 and
>> 1.3 don't address the issue in the sentence quoted.
>
>The last sentence is the one that is misleading. All of the rest of
>the paragraph is just repeation of the text from elsewhere.
>
>The last sentence should be saying:
>
>		  If one of the proposals offered is for the
>   Diffie-Hellman group of NONE, and the responder selects that
>   Diffie-Hellman group, then it MUST ignore the initiator's KE
>   payload and omit the KE payload from the response.
>
>I.e. the MUST ignore, and omit the KE payload is only applicable if
>responder actually selects the Diffie-Hellman group NONE.

That makes good sense to me, and seems like less of a change to 4306 than the current wording. Do others agree?

--Paul Hoffman, Director
--VPN Consortium