Thanks for reviewing this DHT draft. Comments are inline below.
I plan to post an updated draft once we work out the SHA-1 issues on the hiprg
list.
-Jeff
-----Original Message-----
From: kathleen(_dot_)moriarty(_at_)emc(_dot_)com
[mailto:kathleen(_dot_)moriarty(_at_)emc(_dot_)com]
Sent: Thursday, October 20, 2011 7:11 AM
To: gen-art(_at_)ietf(_dot_)org; Ahrenholz, Jeffrey M
Cc: ietf(_at_)ietf(_dot_)org;
draft-irtf-hiprg-dht(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Subject: Gen-ART review for draft-irtf-hiprg-dht-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-irtf-hiprg-dht-04
Reviewer: Kathleen Moriarty
Review Date: October 20, 2011
IETF LC End Date: 11/1/11
IESG Telechat date: (if known)
Summary: This draft requires further review. There are just a few
grammar nits listed below, but the use of SHA-1 should be updated or
noted as a concern.
This is an experimental draft, building off of other experimental RFCs.
The IESG outlined a number of concerns at the start of RFC5201, at
least one of which is also present in this document. SHA-1 is no
longer a preferred algorithm and there is no algorithm agility in the
specification (it appears to be a field size limitation from previous
RFCs, but there is no explanation). This is not listed in the security
considerations either. If the IESG is still okay with experimental
documents proceeding with SHA-1 specified, this should be discussed in
the security considerations section at a minimum. It seems that the
service described could use another hash algorithm since the exchanges
are fully defined in this document.
SHA-1 is prescribed by the OpenDHT interface that this draft aims to support.
If the algorithm cannot be updated, the description of the design in
the abstract should be updated as HIP is not designed with the security
features described in the following sentences.
"The protocol is
designed to be resistant to denial-of-service (DoS) and man-in-the-
middle (MitM) attacks. When used together with another suitable
security protocol, such as the Encapsulated Security Payload (ESP),
it provides integrity protection and optional encryption for upper-
layer protocols, such as TCP and UDP."
This could be a result of RFC5201 having a MUST statement for the use
of SHA-1. The earlier document, RFC4423 specifies a hash is to be used
and at the time it was written, SHA-1 was the NIST recommendation
(2003).
Major issues:
Minor issues:
Nits/editorial comments:
Abstract: Change: This document specifies a common interface for using
HIP with a
To: "This document specifies a common interface for using Host Identity
Protocol (HIP) with a"
The Introduction uses the spelled out acronym without putting (HIP)
after it if you want to define it here as well.
Fixed.
Introduction: 3rd sentence, add a comma:
Change from: "These keys are hashed and prefixed
to form Host Identity Tags (HITs) which appear as large random
numbers."
To: "These keys are hashed and prefixed
to form Host Identity Tags (HITs), which appear as large random
numbers."
Fixed.
Section 2: Is there a reason why the hash value is limited to using
SHA-1? This should be a choice for algorithm agility if possible.
Yes, SHA-1 is prescribed by OpenDHT; it was not a choice made for this protocol.
This is open for discussion on the hiprg list.
Section3, paragraph 6: Consider breaking this into two sentences:
"The host SHOULD
retain the last Update ID value it used for each HIT across reboots,
or perform a self lookup in the DHT, since that number may be
retained in the DHT records and will determine the preferred address
used by peers."
Fixed.
Section 4, paragraph 4: Consider changing the following sentence
(joining two thoughts not three) and 'address publish' does not read
quite right:
From: "The ttl_sec field used with address publish includes the time-
to-
live, the number of seconds for which the entry will be stored by
the
DHT, which SHOULD be set to the number of seconds remaining in the
address lifetime."
To: "The ttl_sec field used with the address publish command includes
the time-to-
Live and the number of seconds for which the entry will be stored by
the
DHT, which SHOULD be set to the number of seconds remaining in the
address lifetime."
Fixed. Also reworded "address publish."
Section 7: Security Considerations
If there is some reason why you can't use anything stronger than SHA-1
for a hash, this should also be listed as a security consideration. I
don't think the IETF is putting through documents that use SHA-1
anymore as standards track.
SHA-1 is used in two ways:
1) put / remove operation
2) reduce the size of the name string for name lookups
Usage #1 is defined by the OpenDHT interface. Usage #2 is not relying on crypto
properties of the hash, just reducing the string length to fit in 160 bits.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf