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

Tommy Pauly <tpauly@apple.com> Thu, 09 February 2017 16:13 UTC

Return-Path: <tpauly@apple.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 4B4C7129B69 for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 08:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 bYKp_cFgJDES for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 08:13:35 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 C11F0129B67 for <ipsec@ietf.org>; Thu, 9 Feb 2017 08:13:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486656775; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BsNRyb7wTnCt28kBrooGH0phIobIYiq8MYF+F/zG9Rc=; b=XiSOqu/yTsJF0Noxb7bcMgE1NWG4PM/SHC5FpoI1frCXNLHjkzp1JdM0di8/9pWM bFLULqyGzWGrHXLfQ8LxhiZ+E0OPoKRi4yYMn0ivcv2ou3YURCajPmFlwUw9z2SB O/b2pjHhp3Wa8SRgSoTUl3X7G6li2MaCOAG1NLKeJ/u4b/aQvsiej8FQ188DrMzV Mz6Lz8ib8mSShSUwwfn2vgXdq3PVVqAiBnIukNnRYjyA8mpuQ6MfMdsOhYfKjiDp xgxl0UrU5vd9GtiSAUG3VmixjbCSSAS8YYrelkP6l/ucCRW4giFwoYsjiBmtoUiw 7Zc8W+RzSU8wUnc6QXRisQ==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id F1.04.10104.7059C985; Thu, 9 Feb 2017 08:12:55 -0800 (PST)
X-AuditID: 11973e12-ad23a9a000002778-b6-589c9507bf76
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay6.apple.com (Apple SCV relay) with SMTP id E7.D7.00867.6059C985; Thu, 9 Feb 2017 08:12:55 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from [17.153.65.195] (unknown [17.153.65.195]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL400LU27PI7I20@nwk-mmpp-sz12.apple.com>; Thu, 09 Feb 2017 08:12:54 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <22684.25414.470545.969594@fireball.acr.fi>
Date: Thu, 09 Feb 2017 08:12:52 -0800
Message-id: <1F3EB5DA-3BF3-45CD-A31E-3D170B5B4F01@apple.com>
References: <22683.8182.349840.103676@fireball.acr.fi> <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com> <22684.25414.470545.969594@fireball.acr.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3263)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYpcs+dU6EwY+nnBb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJWx6udtpoKv4hWfv01ka2B8IdTFyMkhIWAi sWDXJBYQW0hgL6PE720FMPFbs1tYIeKHGCUarzqC2LwCghI/Jt8DqufgYBaQlzh4XhYkzCyg JfH9UStQmAuovItJ4uq3fUwgNcICEhKb9ySC1AgL+EtcXraTEcRmE1CROP5tAzOIzSlgIXF2 fxc7iM0ioCpxas0eJoiZFhJ355xhhVhrIzG99xQzxPzpjBKfFzwDaxARUJTY/WQrE8TNshLd C6eBFUkIbGGTeHriL9MERuFZSO6ehXD3LCR3L2BkXsUolJuYmaObmWeil1hQkJOql5yfu4kR FNbT7YR2MJ5aZXWIUYCDUYmH90XNnAgh1sSy4srcQ4zSHCxK4rxCJjMjhATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTDOuudh5i2gE6DdzR58f9EcocQ335PfHrC8P/t4hvaE4MlSXA1Kjnoq /30ir5g8lBD0EOldF5vwZ9dh1sKGve9lefaybJv3Yf031k3v3Jqj1jfNs24tU508ecnB//tS LhxI2M8gKDFhsxm7y2HZF3euX+5bOPcbt9Op1fmzJ2/Z+O/q76zD1WmTlFiKMxINtZiLihMB 56vifkwCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IRbCg+o8s+dU6EQfNXVov9W16wWRw9/5zN gcljyZKfTB6Hvy5kCWCK4rJJSc3JLEst0rdL4MpY9fM2U8FX8YrP3yayNTC+EOpi5OSQEDCR uDW7hRXCFpO4cG89G4gtJHCIUaLxqiOIzSsgKPFj8j2WLkYODmYBeYmD52VBwswCWhLfH7UC hbmAyruYJK5+28cEUiMsICGxeU8iSI2wgL/E5WU7GUFsNgEViePfNjCD2JwCFhJn93exg9gs AqoSp9bsYYKYaSFxd84ZVoi1NhLTe08xQ8yfzijxecEzsAYRAUWJ3U+2MkHcLCvRvXAa8wRG wVlITp2FcOosJKcuYGRexShQlJqTWGmml1hQkJOql5yfu4kRHKCFUTsYG5ZbHWIU4GBU4uF9 UTMnQog1say4MhcYFBzMSiK8l/uBQrwpiZVVqUX58UWlOanFhxiTgR6YyCwlmpwPjJ68knhD ExMDE2NjM2NjcxNz0oSVxHk998+IEBJITyxJzU5NLUgtgtnCxMEp1cDolMzHENm9TErqTajg g/PMYfxuyUpqTiIsX2Lsdxs36i5VKXIw3HX87+Fg44k+7LEbXKu3e521DPr7++UjP5Ony1dd 998qZ/Kv2mbatMSbD3gdlYW91L3+clffXTV5sZrqZkdb0eOMW1YFf/l8/vEN4T3sprdfTGR5 yr8hZKWFD2O6zgThX85KLMUZiYZazEXFiQDKBcXElAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/1m38QCK0kzgOPYRYNn5UC6lsxZk>
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: Thu, 09 Feb 2017 16:13:37 -0000

Thanks for sending out the corrected draft name, Tero. I think this draft is in good shape in general and we should move forward with it.

The only thing that seems to need ironing out is the specific IANA hash value. I can see the argument either way: as the draft points out, 0 makes sense for the Identity hash, since it can be viewed as "no hash at all". However, I agree with your point that 0 may often be used in code to indicate an uninitialized value. I would be concerned if existing implementations flagged 0 as an error, here, as well.

I think it would make sense to do a quick poll of the WG to get some consensus on this. At this point, I'm mildly in favor of a new value (5).

Thanks,
Tommy

> On Feb 9, 2017, at 4:40 AM, Tero Kivinen <kivinen@iki.fi> 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...
> -- 
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec