Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
draft-ietf-hip-dns-09

[Ballot discuss]
This is a "talk briefly before I clear" discuss.  I am still working to
clarify my understanding of security algorithm agility so I can give good
advice to apps WGs when this issue comes up.  First, this protocol
appears to have no way to identify the hash algorithm used to compute
the HIT.  I would like to understand how the DNS transition works when
that algorithm changes -- would that require a new RR?  Is the hash
algorithm implied by the signature algorithm?  Or is it hard-coded to
SHA-1 and that's OK due to the security consideration in section 8.2
recommending use of the HI rather than HIT?

When the signature algorithm changes, is there a period where both the
old and new algorithms would need to be in the DNS while clients are
upgraded?  If so, how would this be done (perhaps different hostnames?).
Or would each HI experience a flag day where all clients
were forced to upgrade in order to use that HI?

[Ballot comment]
Gen-ART Review by Eric Gray ...

  Last paragraph before section 3.1 (mid page, Page 6), what would be
  an example of "ill effects" mentioned in this paragraph?  It seems
  to me that this statement could probably be more specific.

  Immediately prior to section 5.1, it may be helpful if the authors
  were to add a statement similar to the following:
  >
  > The format of these fields is described in the subsections below.
  >
  While this becomes obvious as you read on, it is usually the case
  that these formats would be provided in the same numbered section
  as that in which the format is depicted.

  I have no idea if I am correctly interpreting the first sentence in
  section 8.2.  It looks as if there was additional text which was
  removed (perhaps another security related technology that is
  susceptible to eventual breakdown?).  It also contains what appears
  to be a parenthetical explanation of why a breakdown in security
  occurs (but this is not very clear, because the sentence seems to
  end prematurely).  And the opening phrase "As many ... eventually
  become insecure," appears to lack a corresponding closing phrase
  that describes the outcome, consequence or result of the opening
  phrase.  From the following sentence, it seems that the intent was
  that the stated methods may not be sufficient.  But that is not
  obvious.  I suggest breaking this sentence up, or re-writing it
  from scratch.

  Nits:

  Last sentence of the first paragraph in section 3.2 (near bottom
  of Page 7):
  >
  > ... its set of IP Address(es).
  >
  should probably be one of:
  >
  > ... its IP Address(es).
  >
  or
  >
  > ... its (set of) IP Address(es).
  or
  >
  > ... its set of IP Addresses.
  >
  The pluralization of Address is not parenthetical as is (meaning it
  cannot be removed with no ill effect on the sentence) - hence it
  should not be parenthesized.

  Last bullet before section 4.2 (toward bottom of Page 9), I believe
  the phrase is "degenerate case" as opposed to "degenerated case"...

  In section 10, fifth line of the first paragraph, "thanks" should
  be "thank" ("... like to thank the following ...").

[Ballot comment]
There are two occurrences of "HPIHI record" in section 6.  I believe that these were intended to
be "HIPHI record" (based on mailing list traffic and old IETF presentations.)  However, those
presentations date from when separate HIPHI and HIPRVS records were used.  A single RR
is now used in the specification, so I guess the name needs to just go away.  (Perhaps they
wre missed in a global search because of the typo?)

IANA Last call Comments:

Upon approval of this document, the IANA will make
the following assignments in the "DOMAIN NAME SYSTEM
PARAMETERS" registry located at

http://www.iana.org/assignments/dns-parameters

sub-registry "In the Internet (IN) class the following Resource
Record (RR) TYPEs and QTYPEs are defined"

TYPE value and meaning Reference
---------- -------------------------------------- ---------
HIP TBD (suggested 55) Host Identity Protocol [RFC-hip-dns-09]

We understand the above to be the only IANA Action for
this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Gonzalo Camarillo, who has
personally reviewed this document and believes it is ready to be
forwarded to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, it has been thoroughly reviewed both inside and outside the WG.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The whole WG is behind this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, this document has normative and informative references. The HIP WG
has already requested the publication of its two normative dependencies.

(1.i) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies a new resource record (RR) for the Domain
Name System (DNS), and how to use it with the Host Identity Protocol
(HIP.) This RR allows a HIP node to store in the DNS its Host
Identity (HI, the public component of the node public-private key
pair), Host Identity Tag (HIT, a truncated hash of its public key),
and the Domain Names of its rendezvous servers (RVS.)


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?


Yes, a number of vendors are already implementing this draft.