Re: [Hipsec] WGLC: draft-ietf-hip-rfc5205-bis

[Julien Laganier <[e-mail]>]

Hi Tom,

Thank you for you review. Please see inline below the proposed
resolution of your WGLC comments.

--julien

> On 04/05/2015 5:23 PM, Tom Henderson wrote:
>> On 04/17/2015 03:47 AM, Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> I would like to start a WGLC on the following draft. This WGLC will end
>>> on May 4th:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/
>>>
>>> Please, send your comments to this list.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>
>> I had a fresh read of this specification and have the following comments.
>>
>> (possibly) technical
>> --------------------
>>
>> RFC 7401 specifies ECDSA and ECDSA_LOW as separate algorithm types, but
>> this document only mentions ECDSA.  For alignment with RFC 7401, I
>> suggest to replace references to "ECDSA" with "ECDSA and ECDSA_LOW" as
>> appropriate (it seems to me that they can reuse the same code point).

The HIP DNS support re-uses the existing DNS KEY RR encoding for
ECDSA, however AFAIK there is no DNS KEY RR encoding for ECDSA_LOW.
Also, since presumably ECDSA_LOW support is present in RFC 7401 for
tightly constrained device,  and given that it isn't immediately clear
whether such tightly constrained device would use the DNS at all to
resolve HIP information of their peer, at this time I'd rather keep
ECDSA_LOW out-of-scope for this specification.

>> I could not find discussion about TTL considerations; are there any?  If
>> there are no special considerations about TTL, caching, and how records
>> may be updated, perhaps it would be helpful to state this (and possibly
>> reference the specification that describes how to expire resource records).

I've clarified the TTL handling of the HIP resource records by adding
the following paragraph to sec 4.2:

   The HIP resource records have a Time To Live (TTL) associated with
   them.  When the number of seconds that passed since the record was
   retrieved exceeds the record's TTL, the record MUST be considered to
   be no longer valid and deleted by the entiry that retrieved it.  If
   access to the record is necessary to initiate communication with the
   entity to which the record corresponds, a new query MUST be be made
   to retrieve a fresh copy of the record.

>> The document doesn't seem to have any discussion of what to do when a
>> host wants to register more than one host identity.  I suggest something
>> along the lines of "there may be multiple HIP RRs associated with a
>> single name.  It is outside the scope of this specification as to how a
>> host chooses from between multiple RRs when more than one is returned.
>> The RVS information may be copied and aligned across multiple RRs, or
>> may be different for each one; a host SHOULD check that the RVS used is
>> associated with the HI being used, when multiple choices are present."

Thanks, I've added the text you proposed to sec. 4.2 but I've used
MUST instead of SHOULD.

>> editorial
>> ---------
>>
>> IANA considerations could be made more explicit about exactly what we
>> are requesting IANA to do; e.g., "the reference to the RR type code
>> should be updated from RFC 5205 to this specification."  and "this
>> document requests that IANA allocate a new codepoint for 'ECDSA and
>> ECDSA_LOW' in the existing registry for IPSECKEY RR."

Done. The IANA considerations has been update and now reads:

9.  IANA Considerations

   IANA is requested to replace references to [RFC5205] by references to
   this document in the the DNS RR type code registry.

   IANA is requested to allocate the following algorithm type in the
   IPSECKEY RR [RFC4025] registry:

      [IANA-TBD] is ECDSA

>> Suggest to replace "Singly" with "Single" and "degenerated" with
>> "degenerate".

done.