A Method for Storing IPsec Keying Material in DNS
draft-ietf-ipseckey-rr-12

Received changes through RFC Editor sync (changed abstract to 'This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]')

[Ballot comment]
New text is better. Thanks. Some minor wordsmithing suggested for first
two paragraphs:

  Suppose we have a host which wishes (or is required by policy) to
  establish an IPsec tunnel with some remote entity on the network
  prior to allowing normal communication to take place.  In many
  cases this end system will be able to determine the DNS name for
  the remote entity (either by having the DNS name given explicitely,
  by performing a DNS PTR query for a particular IP address, or
  through some other means, e.g., by extractng the DNS portion of a
  "user@FQDN" name for a remote entity).  In these cases the host
  will need to obtain a public key in order to authenticate the
  remote entity, and will also need some guidance about whether it
  should contact the entity directly or use another node as a gateway
  to the target entity. The IPSECKEY RR provides a storage mechanism
  for storing such information.

[Ballot discuss]
Meta issue (this is why I'm putting in a discuss):

Intro (actually no part of the document) actually explains what this
RR is useful for. Consider a reader not familar with this effort who
would like to understand why this RR is needed, who uses it, and in
what situations its useful.  For instance, it would be useful to
include an example of how the RR is expected to be used. I.e., it's
not until halfway down the document that one figures out the RR could
identify a gateway one connects to to create an IPsec tunnel to a
particular site. But the RR is keyed by an address. Why does one need
to map from the address to a gateay? I suspect 1 or 2 paragraphs would
do the trick.

Specific comments:

Abstract could be a lot better. Reading it, one doesn't really know
what this document is about or how the RR is used.


>    The RDATA for an IPSECKEY RR consists of a precedence value, a public
>    key, algorithm type, and an optional gateway address.

picture also shows a 'gateway type' field...

> 2.2 RDATA format - precedence
>
>    This is an 8-bit precedence for this record.  This is interpreted in
>    the same way as the PREFERENCE field described in section 3.3.9 of
>    RFC1035 [2].

say "unsigned"? also, why not just specify the semantics of the
preference here, rather than pointing to a (rather unrelated) MX
record RR? Hunting for the MX text in another document seems
suboptimal (and results in an odd normative reference).

>    Gateways listed in IPSECKEY records with  lower precedence are to be
>    attempted first.  Where there is a tie in precedence, the order
>    should be non-deterministic.

Note: the above text seems out of place, given the previous paragraph
which just points to MX. Can't you just specify the behavior here (in
its entirety) and remove the normative dependency?

>    3  A wire-encoded domain name is present.  The wire-encoded format is
>      self-describing, so the length is implicit.  The domain name MUST
>      NOT be compressed.
>

"wire-encoded" could be made more precise. I.e., Refer to DNS spec
(and specific section?). (There is better text later in the draft, actually)


>    A 32-bit IPv4 address is present in the gateway field.  The data
>    portion is an IPv4 address as described in section 3.4.1 of RFC1035
>    [2].  This is a 32-bit number in network byte order.
>
>    A 128-bit IPv6 address is present in the gateway field.  The data
>    portion is an IPv6 address as described in section 2.2 of RFC1886
>    [7].  This is a 128-bit number in network byte order.

Why are (apparently normative) references to other RRs given here?
Can't the format just be written out here, since it's basically one
sentence saying N-bits in network byte order?


> 5. IANA Considerations
>
>    This document updates the IANA Registry for DNS Resource Record Types
>    by assigning type X to the IPSECKEY record.

Add:

This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record.

[Ballot comment]
The end of Section 4 says:

  Any user of this resource record MUST carefully document their trust
  model, and why the trust model of DNSSEC is appropriate, if that is
  the secure channel used.

Does that really mean "any user"? Do we require end-users of our specifications to generate documentation these days? If this is instead referring to derivate specifications or IETF-shepherded operational models based on these RRs, it should say so explicitly here.

Nit: Should we encourage/require people who use xml2rfc to use the  directive? The amount of whitespace that is generated otherwise is a little bothersome.

[Ballot discuss]
This may have an easy reply, but....
if one is using unsecured DNS, a man-in-the-middle attack can be mounted. The document claims that this can only be done when there is a value in the gateway field.
If an attacker can attack the DNS for the IPSECKEY record, the attacker should also be able to attack the A record. Wouldn't that allow the same attack as for the case where a gateway field is present?
If so, shouldn't the security considerations say so?

[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the examples, replace ip6.int with ip6.arpa.

In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).

[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).

[Ballot comment]
In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).

[Ballot discuss]
DISCUSS.

From OPS directorate review:

> o draft-ietf-ipseckey-rr-07.txt
> A method for storing IPsec keying material in DNS (Proposed Standard) - 10
> of 14
> Token: Steve Bellovin

Bigger issue:

- The examples use the reverse DNS records to convey IPSECKEY record.
Does this have some unstated assumptions about the deployment of
IPSECKEY (e.g., to be usable, the participating nodes should record
the RRs in reverse records), or is this just a coincidence?
I note that the document does not discuss the deployment at all, but
that is probably intentional.

If there is no connection to the reverse records, I'd suggest
rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com
IN IPSECKEY ..."; if there is a requirement for reverse records, this
issue needs to be explicitly discussed.. DNS deployment folks might
have something to say about that :-)

Nits:

- Reorder sections 2.3 and 2.4 to be in the saem order as the fields.

- Replace the references to RFC1886 with RFC3596.

- Add IPR section

- Rename the draft shortname (at each page header) from "ipsecrr" to
something else.

- Remove the dot from the title and upper-case it.

[Ballot comment]
This text:

2.1 IPSECKEY RDATA format

  The RDATA for an IPSECKEY RR consists of a precedence value, a public
  key, algorithm type, and an optional gateway address.

seems to leave out gateway type, described in section 2.4.  The rest of
the document is clear, but it would probably be good to add it in here.

Remaining nits:

Remaining nits, for reference:

> Just read -07.  One final nit, sigh: s/ip6.int/ip6.arpa/

And in the IANA section, for the second registry:
s/Algorithm numbers/Gateway type numbers/