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

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 <tpauly@apple.com> wrote:
> 
> 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
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec