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

From: The IESG <[email-masked]>
Date: Mon, 14 May 2007 09:50:50 -0400

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
[email-masked] mailing lists by 2007-05-28. Exceptionally, 
comments may be sent to [email-masked] 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

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12489&rfc_flag=0

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 May 2007 08:23:49 +0300 (EEST)

> 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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 29 May 2007 16:10:02 +0300

Hi Pekka,

I don't have answers to all of your questions/remarks, but I'd take  
forward a few:

> ==> what if it does not?

Remember that this is an experimental spec.  So, taking it the  
reverse, why should id specify what to do if someone has a reason to  
do it in another way?

I don't see any specific reason to make any MUSTs or even SHOULDs  
here: I don't see here any danger for the Internet nor  
interoperability.  But maybe I just don't understand the dangers you  
have in your mind.

> ==> this seems like a premature optimization.

Note that these RRs may need to be indexed also by other boxes but  
the end-nodes.  For them, using the HIT as an index and doing a  
simple memory comparison instead of calculating a hash may be a win.   
Further note that both the sections you quote above discuss only host/ 
end-note behaviour.

> is checked;

I agree.  FWIW, either ignore the HIT or drop the record.  I think  
the latter would be the right option, but I may be wrong.

> 2) what are the threats if HIT is used as-is without

I don't understand what you are saying here.

--Pekka (the other one)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 May 2007 22:58:23 +0300 (EEST)

On Tue, 29 May 2007, Pekka Nikander wrote:
> I don't have answers to all of your questions/remarks, but I'd take forward a 
> few:
>
> Remember that this is an experimental spec.  So, taking it the reverse, why 
> should id specify what to do if someone has a reason to do it in another way?
>
> I don't see any specific reason to make any MUSTs or even SHOULDs here: I 
> don't see here any danger for the Internet nor interoperability.  But maybe I 
> just don't understand the dangers you have in your mind.

I have personally no big problems if the spec were to say that 
"HIP-after-A-or-AAAA" were to be left out of scope of this document.

However, what I'm a bit uncomfortable with is that this assumption is 
apparently made in Section 3, "Usage Scenarios", which seems to be a 
section with no normative content.  As such I believe such a 
statement/assumption (if made) should be made in a more prominent 
place in the spec.

> Note that these RRs may need to be indexed also by other boxes but the 
> end-nodes.  For them, using the HIT as an index and doing a simple memory 
> comparison instead of calculating a hash may be a win.  Further note that 
> both the sections you quote above discuss only host/end-note behaviour.

This is makes me even more afraid.  If most end-nodes use mechanism A 
but others are expected to maybe use another mechanism B, I foresee 
problems with both mechanisms especially in middleboxes.  It certainly 
won't improve the reliability of the protocol..

>> 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;
>
> I agree.  FWIW, either ignore the HIT or drop the record.  I think the latter 
> would be the right option, but I may be wrong.
>

Maybe I was trying to be too terse or I'm missing an assumption about 
how HIT vs HI is validated in other parts of HIP infrastructure.

Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else 
has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create an 
intentional conflict.

Given that the spec does not mandate that the implementations check 
that HIT will correspond to the HI, what's going to happen in this 
case?

Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, 
what is the result?  Will it be a DoS on the host that used HI=Y?

That was the scenario 2.a) above and 2.b) is when HITs don't conflict 
(a more trivial case)

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 30 May 2007 11:20:26 +0300

> I have personally no big problems if the spec were to say that "HIP- 
> after-A-or-AAAA" were to be left out of scope of this document.
>
> However, what I'm a bit uncomfortable with is that this assumption  
> is apparently made in Section 3, "Usage Scenarios", which seems to  
> be a section with no normative content.  As such I believe such a  

A suitable restriction of the scope, at an appropriate place, would  
be fine with me.

>> simple memory comparison instead of calculating a hash may be a  
>> win.  Further note that both the sections you quote above discuss  
>> only host/end-note behaviour.
>
> This is makes me even more afraid.  If most end-nodes use mechanism  
> A but others are expected to maybe use another mechanism B, I  
> foresee problems with both mechanisms especially in middleboxes.   
> It certainly won't improve the reliability of the protocol..

So, maybe add a paragraph about the usability of the HIT for middle  
boxes.

IIRC, the context of discussion was HIP-aware firewalls.  Such  
firewalls could simply snoop HIT RRs as they pass by (or even query  
them if there is a suitable reverse DNS hierarchy, which the draft  
does NOT specify, IIRC).  Then, when they see HIP I2/R2 packets  
passing by, they could use the cached keys, as indexed by the HITs,  
to verify the signatures in the messages.

For such use, I don't see any need of verifying the cryptographic  
relationship between the HIT and HI.  If the signatures in the I2/R2  
don't match, then the firewall doesn't open the connection, and it is  
the user's problem.  No security dangers, AFAICS.  Indeed, it would  
be beneficial if the firewall did NOT try to establish any crypto  
relationship between the HIT and HI, since that would allow the  
relationship to evolve without mandating firewall code updates.

> Maybe I was trying to be too terse or I'm missing an assumption  
> about how HIT vs HI is validated in other parts of HIP infrastructure.
>
> has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create  
> an intentional conflict.
>

You will fail to gain the channel binding property of HIP.  In other  
words, you shoot to your own foot.

> what is the result?  Will it be a DoS on the host that used HI=Y?

Well, nothing if the middlebox is implemented correctly.  HIT  
collisions are possible, anyway.  Hence, in such a case the middlebox  
should cache both HI=X and HI=Y, indexed by the HIT.  The fact that  
HIT!=hash(X) shouldn't matter.

--Pekka

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 30 May 2007 10:59:20 -0700

> RR zone data, i.e., can any authoritative DNS server implementation 

We've implemented a previous version on this draft as a patch to ISC's
BIND 9.x implementation. I don't know whether or not authoritative DNS
servers are running BIND, but it does have functions such as
isc_hex_totext() and isc_base64_totext() for Base(16,64) conversions.
This doesn't seem very different than RFC4025 (IPSECKEY RR).

-Jeff