[Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC

[Pekka Savola <[e-mail]>]

On Mon, 14 May 2007, The IESG wrote:
> The IESG has received a request from the Host Identity Protocol WG (hip)
> to consider the following document:
>
> - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions '
>   <draft-ietf-hip-dns-09.txt> as an Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2007-05-28. Exceptionally,
> comments may be sent to [e-mail] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt

It's still May 28th in some parts of the world, I guess :-)

Here's my review.

I wonder if there are privacy or operational considerations with 
publishing one's rendezvous servers in the DNS, but I can't think of 
anything serious. I wonder if there are precedents to publishing 
similar "proxy" configurations in the DNS, and whether there is 
anything to learn of past experiences with that.

My main issues are with expressing HIT in the wire format, and a doubt 
about whether an authoritative DNS servers must support Base{16,64} 
algorithms and how to apply them to create wire-representation of HIP 
RR zone data, i.e., can any authoritative DNS server implementation 
_today_ support HIP RRs?

substantial
-----------

1) what if HIP RRs are not queried first?

    In the following we assume that the initiator first queries for HIP
    resource records at the responder FQDN.

==> what if it does not?  Should you phrase this differently, i.e., as a
mandatory requirement for the implementations that conform to this spec?  On
the other hand, if it's not a mandatory requirement, then you should
describe how this will work, at least on a high level.  (There is a reason I
ask this: some implementations already look up A records before AAAA records
to prevent damage from badly behaving DNS implementations; I'd expect that a
resolver might do the same with HIP RRs.)

2) usage scenarios

    Depending on the combinations of answers the situations described in
    Section 3.1 and Section 3.2 can occur.
...
3.1.  Simple static singly homed end-host
3.2.  Mobile end-host

==> these are the two described usage scenarios.  I was left wondering a bit
what about the rest, for example, a dual-homed (static) end-host.   I guess
that scenario is similar to the mobile end-host.  I further guess the list of
scenarios is not meant to be exhaustive but more explicit text might not
hurt.

3) a premature optimization of HIT lookup tags

    Upon return of a HIP RR, a host MUST always calculate the HI-
    derivative HIT to be used in the HIP exchange, as specified in
    Section 3 of the HIP base specification [I-D.ietf-hip-base], while
    the HIT possibly embedded along SHOULD only be used as an
    optimization (e.g. table lookup).

.. and in section 8.2:

    [...] This is why a HIP
    end-node implementation SHOULD NOT authenticate its HIP peers based
    solely on a HIT retrieved from the DNS, but SHOULD rather use HI-
    based authentication.

==> this seems like a premature optimization.  The cost of producing a hash
of a public key is irrelevant compared to the computing overhead and latency
caused by DNS lookups.  As such, using the HIT as an on-the-wire optimization
should probably be removed from the spec.  It should also be removed from the
resource record format as well as from the wire.

The problem if we go forward as it is, is what to do with this extra
information.  We could make it stronger (e.g., "MUST ignore") but then it
would be only wasted bits.  If there aren't too many implementations already
(given that the RR type hasn't been allocated) this might be changeable.

If you go forward as it is, I think the spec needs to be more explicit on 1)
what happens when HIT received from the DNS does not match the hash but the hash
is checked; 2) what are the threats if HIT is used as-is without
hash-checking (as allowed by the spec at the moment) when a) the DNS-HIT
points to something used by another HI, and b) the DNS-HIT doesn't exist.

4) more protective specification needed

Section 5
    The HIT length, PK algorithm, PK length, HIT and Public Key field are
    REQUIRED.  The Rendezvous Servers field is OPTIONAL.

Section 5.6
    The domain names MUST NOT be compressed.

==> this spec is written to be conservative what it generates, but receiver
behaviour on malformed behaviour is unspecified.  Does it need to be?

5) HIP wire format vs zone representation

    The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
    hex or hexadecimal) of the HIT.  The encoding MUST NOT contain
    whitespaces to be able to distinguish it from the public key field.

    The Public Key field is represented as the Base64 encoding [RFC4648]
    of the public key.  The encoding MUST NOT contain whitespace(s) to be
    able to distinguish from the Rendezvous Servers field.

==> I may me misunderstanding this, but doesn't that imply that the
authoritative DNS servers must implement Base16 and Base64 decoding support
so that they can convert from BaseXX to the on-the-wire format?

Is this a new requirement on DNS nameserver implementations, or are DNS
servers already required to do it?   Is this a typical way to represent and
distribute binary data on DNS?

Does this require the authoratative DNS server to know how to parse the zone
representation format, i.e., "support for HIP RRs"?

My question here would be, how would DNS authoritative servers support HIP RRs
under RFC3597 ("Handling of Unknown DNS Resource Record (RR) Types")?



editorial
---------

    o  A set of IP address(es) through A [RFC1035] and AAAA [RFC3596] RR
       sets (RRSets [RFC2181]).

==> you'll probably want to rephrase this as:

    o  A set of IP address(es) through A [RFC1035] and AAAA [RFC3596]
       resource record sets (RRSets [RFC2181]).

.. or remove "(RRsets ..") and just keep the 2181 reference.

    The RDATA for a HIP RR consists of a public key algorithm type, the
    HIT length, a HIT, a public key, and optionally one or more
    rendezvous server(s).

==> s/algorithm type/algorithm type and length/

    The complete representation of the HPIHI record is:

==> s/HPIHI/HIPHI/ (?) -- the same elsewhere

    The HIP RR contains public keying material in the form of the named
    peer's public key (the HI) and its secure hash (the HIT).  Both of
    these are not sensitive to attacks where an adversary gains knowledge
    of them.

==> s/Both of these are not/Neither of these are/ ?

    Hannu Flinck, Olafur Gu[eth]mundsson, Tom Henderson, Peter Koch, Olaf

==> Olafur's surname might need ascii-fication..

    Julien Laganier is partly funded by Ambient Networks, a research
    project supported by the European Commission under its Sixth
    Framework Program.  The views and conclusions contained herein are
    those of the authors and should not be interpreted as necessarily
    representing the official policies or endorsements, either expressed
    or implied, of the Ambient Networks project or the European
    Commission.

==> is such a long boilerplate really necessary?  I'd hate to start seeing
these on each I-D, for each author for different sponsors, etc.   A shorter,
3 lines maximum, acknowledgement should be sufficient.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec