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

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Feb 2017 15:41:10 +0200

This message will start two week working group last call for the
draft-nir-ipsecme-eddsa-00 [1] draft.

Please send your comments, questions etc to WG mailing list before
2017-02-24. If you belive that the document is ready to be submitted
to the IESG for consideration as a standard track RFC please send a
short message stating this also.

This document has been mostly ready for some time, but we have been
waiting for curdle and cfrg to do some work needed for this. Firstly
we needed to get oids from the curdle, and the
draft-ietf-curdle-pkix-03 [2] allocating the oids is in the WGLC in
curdle WG.

Secondly we have been waiting for the CFRG to decide wheter we should
use contextes or not. This is same issue than in the TLS wg, so we go
with the same resolution. CFRG has now decided [3] that no contexes is
used in TLS case, and as IPsec is in similar situation, we go with
that.

So as those things we have been waiting for, are now cleared this
document can now go forward.

[1] https://datatracker.ietf.org/doc/draft-nir-ipsecme-eddsa/
[2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
[3] https://www.ietf.org/mail-archive/web/cfrg/current/msg08934.html
-- 
[email-masked]

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Feb 2017 11:01:43 -0800

Tero,

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.

Minor typo in the introduction:
    "we define a new value has in the SIGNATURE_HASH_ALGORITHMS notification,"
    s/value has in/value hash in/

Thanks,
David

> On Feb 8, 2017, at 05:41, Tero Kivinen <[email-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Feb 2017 14:40:38 +0200

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.

> 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...
-- 
[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 09 Feb 2017 08:12:52 -0800

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 <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Feb 2017 11:57:52 -0500

Yes I forgot to reply. I strongly object to assigning 0 for real values. It should be left for implementations to detect a value has not been set.

Paul

Sent from my iPhone

> On Feb 9, 2017, at 11:12, Tommy Pauly <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 Feb 2017 09:21:21 -0800

Based on these arguments, I agree that a new value (5) is preferable to 0.

David

> On Feb 9, 2017, at 08:57, Paul Wouters <[email-masked]> wrote:
>

---

From: Andreas Steffen <[email-masked]>
Date: Wed, 15 Feb 2017 10:09:02 +0100

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

> better, feel free to tell me...

======================================================================
Andreas Steffen                         [email-masked]
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]==

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Feb 2017 17:11:01 +0200

> the code point has been assigned.

Before we can make code point allocation, we need to agree on whether
it is going to be zero or next number. As you can see from the emails
in this list there is not agreement on this yet, so even if authors
make IANA request to ask for assignment, when it comes to me (as for
expert review) few days later, I would wait for the comments on the
list to agree on which number we are going to allocate.

Now it seems more people are supporting allocating something else than
zero... 

> > then send it to the expert (me) for verification.

And then we will then come back to this list to finish this
discussion...
-- 
[email-masked]