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

Andreas Steffen <andreas.steffen@strongswan.org> Wed, 15 February 2017 09:09 UTC

Return-Path: <andreas.steffen@strongswan.org>
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 8FAFD128AC9 for <ipsec@ietfa.amsl.com>; Wed, 15 Feb 2017 01:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2vEp71oHKbYD for <ipsec@ietfa.amsl.com>; Wed, 15 Feb 2017 01:09:05 -0800 (PST)
Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B65F128B38 for <ipsec@ietf.org>; Wed, 15 Feb 2017 01:09:05 -0800 (PST)
Received: from [152.96.214.154] (unknown [152.96.214.154]) by mail.strongswan.org (Postfix) with ESMTPSA id 71D1E40170; Wed, 15 Feb 2017 10:09:02 +0100 (CET)
To: Tero Kivinen <kivinen@iki.fi>
References: <22683.8182.349840.103676@fireball.acr.fi> <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com> <22684.25414.470545.969594@fireball.acr.fi>
From: Andreas Steffen <andreas.steffen@strongswan.org>
Message-ID: <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org>
Date: Wed, 15 Feb 2017 10:09:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <22684.25414.470545.969594@fireball.acr.fi>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000105060301070507060407"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/_mN3aRB7jk5i_SLeHQmQaQgJd3c>
Cc: ipsec@ietf.org, David Schinazi <dschinazi@apple.com>
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: Wed, 15 Feb 2017 09:09:07 -0000

Hi Tero,

I personally think that 0 would have been legitimate for the "Identity"
hash but the next unassigned value (5) is also ok for me.

Could you please ask IANA for an early assignment of the code point?
strongSwan 5.5.2 with Ed25519 support is ready to be deployed,
thus we would be able to release the stable version as soon as
the code point has been assigned.

Best regards

Andreas Steffen

On 09.02.2017 13:40, Tero Kivinen wrote:
> 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...
> 

======================================================================
Andreas Steffen                         andreas.steffen@strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==