Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

Tero Kivinen <kivinen@iki.fi> Thu, 09 February 2017 12:40 UTC

Return-Path: <kivinen@iki.fi>
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 5527F1299DA for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 04:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 IFtudnp_JcpF for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 04:40:49 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 2D4731299CC for <ipsec@ietf.org>; Thu, 9 Feb 2017 04:40:48 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v19Cec9B024490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Feb 2017 14:40:38 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v19CeceM029258; Thu, 9 Feb 2017 14:40:38 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22684.25414.470545.969594@fireball.acr.fi>
Date: Thu, 09 Feb 2017 14:40:38 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: David Schinazi <dschinazi@apple.com>
In-Reply-To: <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com>
References: <22683.8182.349840.103676@fireball.acr.fi> <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 11 min
X-Total-Time: 13 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RiduXpY7Z4qRW59RF7jF4g55gRk>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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, 09 Feb 2017 12:40:50 -0000

Ah I noticed that my last call email had wrong draft name in the
subject line and in the link. The correct draft name is of course
draft-ietf-ipsecme-eddsa-00 not *-nir-* version.

David Schinazi writes:
> I've reviewed this draft. I support it and believe it is ready to move forward
> towards becoming a standards-track RFC. Also, would it make sense to ask
> IANA for early assignment of the code point? Using 0 sounds reasonable to me.

As this is expert review registry there is no need to ask for early
allocation, the normal process is just to fill in the IANA general
request for assignments, which then goes to the IANA and they will
then send it to the expert (me) for verification.

If normal number (other than 0) would be given out, then I would just
say yes, but allocating 0, which in registry is marked as:

	0 	Reserved 	[RFC7427]

and is not part of the :

	5-1023 	Unassigned

range, then I would be bit more hesitant to give it out, and would
most likely want to poll the WG and list before making decision.

I actually myself think it would be better to just allocate next free
number from the unassigned space, and keep the value 0 as reserved...

For example we do not use value 0 of Encryption Algorithms transform
to mean ENCR_NULL, we do have separate number allocated for it. On the
other hand we do have value 0 meaning NONE in the Integrity algorithm
transform ID table and for diffie hellman values, but there the
meaning is bit different, it means there is no value for that id, here
it would be meaning that there is this identity function version of
the hash function. 

As an expert and as a implementor I think I would prefer next free
number over 0... Quite commonly in the code we use value 0 as meaning,
we have not yet received anything, or we have not yet initialized this
field, and having separate value for identity function might make
things easier. But if others have good reasons why the value 0 is
better, feel free to tell me...
-- 
kivinen@iki.fi