Subject: [IPSECKEY] Re: ipseckey out of iesg (part deux)

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2003 17:53:34 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    IESG> Thomas Narten:

    IESG> Discuss:
    IESG> Meta issue (this is why I'm putting in a discuss):
    IESG> 
    IESG> Intro (actually no part of the document) actually explains what this
    IESG> RR is useful for. Consider a reader not familar with this effort who
    IESG> would like to understand why this RR is needed, who uses it, and in
    IESG> what situations its useful.  For instance, it would be useful to
    IESG> include an example of how the RR is expected to be used. I.e., it's
    IESG> not until halfway down the document that one figures out the RR could

I use the word "entity" rather than end system. Perhaps this is wrong.

The document now reads:

Abstract

   This document describes a new resource record for DNS.  This record
   may be used to store public keys for use in IPsec systems.  The
   record also includes provisions for indicating what IP address (v4 or
   v6) should be contacted when establishing an IPsec tunnel with the
   entity in question.

   This record replaces the functionality of the sub-type #1 of the KEY
   Resource Record, which has been obsoleted by RFC3445.

...

1. Introduction

   It postulated that there is an end system desiring to establish an
   IPsec tunnel with some remote entity on the network.  This system,
   having only a DNS name of some kind (forward, reverse or even
   user@FQDN) needs a public key to authenticate the remote entity.  It
   also desires some guidance about whether to contact the entity
   directly, or whether to contact another entity, as a gateway to that
   entity.

   The IPSECKEY RR provides a storage mechanism for such items as the
   public key, and the gateway information.

   The type number for the IPSECKEY RR is TBD.

-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2003 17:42:47 -0500

-----BEGIN PGP SIGNED MESSAGE-----

The IESG has made the following comments, which you can read at:

    https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1082&filename=draft-ietf-ipseckey-rr

I include the comments below, as a quote, and am responding to them,
as I act on them.

    IESG> Last Call to expire on: 2003-11-17

    IESG>         Please return the full line with your position.

    IESG>                       Yes  No-Objection  Discuss  Abstain
    IESG> Harald Alvestrand    [   ]     [ XX]     [ X ]     [   ]
    IESG> Steve Bellovin       [ X ]     [   ]     [   ]     [   ]
    IESG> Bill Fenner          [   ]     [ X ]     [   ]     [   ]
    IESG> Ned Freed            [   ]     [ X ]     [   ]     [   ]
    IESG> Ted Hardie           [   ]     [ X ]     [   ]     [   ]
    IESG> Russ Housley         [   ]     [ X ]     [   ]     [   ]
    IESG> Allison Mankin       [ X ]     [   ]     [   ]     [   ]
    IESG> Thomas Narten        [   ]     [   ]     [ X ]     [   ]
    IESG> Jon Peterson         [   ]     [ X ]     [   ]     [   ]
    IESG> Margaret Wasserman   [   ]     [ X ]     [   ]     [   ]
    IESG> Bert Wijnen          [   ]     [   ]     [ X ]     [   ]
    IESG> Alex Zinin           [   ]     [ X ]     [   ]     [   ]

    IESG> 2/3 (9) Yes or No-Objection opinions needed to pass.

    IESG> DISCUSSES AND COMMENTS:
    IESG> ======================
    IESG> Ned Freed:

    IESG> Comment:
    IESG> No IPR boilerplate

  Added. I didn't find anything in the IRP WG's documents with a template.
I took one from the first RFC I found that had one, which happened to be
3584.txt. 

    IESG> Ted Hardie:

    IESG> Comment:
    IESG> This text:
    IESG> 
    IESG> 2.1 IPSECKEY RDATA format
    IESG> 
    IESG>    The RDATA for an IPSECKEY RR consists of a precedence value, a
    IESG>    public key, algorithm type, and an optional gateway address.
    IESG> 
    IESG> seems to leave out gateway type, described in section 2.4.  The
    IESG> rest of the document is clear, but it would probably be good to add
    IESG> it in here. 

  Fixed.

    IESG> Allison Mankin:

    IESG> Comment:
    IESG> Instead of RFC1521 for Base64 (v. old), reference RFC3548.

  Done.

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

  Already done in my copy.

    IESG> In the IANA Considerations, there's a typo:
    IESG> 
    IESG> This document creates an IANA registry for the algorithm type field.
    IESG> 
    IESG>    Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
    IESG>    through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
    IESG> 
    IESG>    This document creates an IANA registry for the gateway type field.
    IESG> 
    IESG>    Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm
    IESG>    numbers 4 
                                                                            
    IESG>            ^ Gateway type
    IESG>    through 255 can be assigned by Standards Action (see RFC2434 [6]).

  Fixed.

    IESG> Thomas Narten:

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

  Hmm. The purpose of this WG is to replace the functionality lost in the
RFC3445. 2535 doesn't say what the record is for either. So I feel that this
is really putting a higher standard on this record than there was in 2535.

  In addition, we carefully avoided saying very much about what the key
means, (semantics), since that goes towards usage. We did say that any system
that defines semantics must specify this stuff. Having grumbled, my next
message contains suggested text, since I want to highlight this.

    IESG> 
    IESG> >    The RDATA for an IPSECKEY RR consists of a precedence value, a public
    IESG> >    key, algorithm type, and an optional gateway address.
    IESG> 
    IESG> picture also shows a 'gateway type' field...

  Already caught above.

    IESG> 
    IESG> > 2.2 RDATA format - precedence
    IESG> > 
    IESG> >    This is an 8-bit precedence for this record.  This is interpreted in
    IESG> >    the same way as the PREFERENCE field described in section 3.3.9 of
    IESG> >    RFC1035 [2].
    IESG> 
    IESG> say "unsigned"? also, why not just specify the semantics of the
    IESG> preference here, rather than pointing to a (rather unrelated) MX
    IESG> record RR? Hunting for the MX text in another document seems
    IESG> suboptimal (and results in an odd normative reference).

  Chairs? Copy and paste from 1035?
  We already reference 1035 for other reasons.

    IESG> >    Gateways listed in IPSECKEY records with  lower precedence are to be
    IESG> >    attempted first.  Where there is a tie in precedence, the order
    IESG> >    should be non-deterministic.
    IESG> 
    IESG> Note: the above text seems out of place, given the previous paragraph
    IESG> which just points to MX. Can't you just specify the behavior here (in
    IESG> its entirety) and remove the normative dependency?

  We could do that. Chairs?

    IESG> >    3  A wire-encoded domain name is present.  The wire-encoded format is
    IESG> >       self-describing, so the length is implicit.  The domain name MUST
    IESG> >       NOT be compressed.
    IESG> > 
    IESG> 
    IESG> "wire-encoded" could be made more precise. I.e., Refer to DNS spec
    IESG> (and specific section?). (There is better text later in the draft,
    IESG> actually) 

  I've added a reference to 1035, 

    IESG> >    A 32-bit IPv4 address is present in the gateway field.  The data
    IESG> >    portion is an IPv4 address as described in section 3.4.1 of RFC1035
    IESG> >    [2].  This is a 32-bit number in network byte order.
    IESG> > 
    IESG> >    A 128-bit IPv6 address is present in the gateway field.  The data
    IESG> >    portion is an IPv6 address as described in section 2.2 of RFC1886
    IESG> >    [7].  This is a 128-bit number in network byte order.
    IESG> 
    IESG> Why are (apparently normative) references to other RRs given here?
    IESG> Can't the format just be written out here, since it's basically one
    IESG> sentence saying N-bits in network byte order?

  Chairs? 
  The reference seems appropriate to me, but I don't care.

    IESG> > 
    IESG> >    This document updates the IANA Registry for DNS Resource
    IESG> >    Record Types 
    IESG> >    by assigning type X to the IPSECKEY record.
    IESG>  
    IESG> Add:
    IESG> 
    IESG> This document creates two new IANA registries, both specific to the
    IESG> IPSECKEY Resource Record.

  Done.

    IESG> Jon Peterson:

    IESG> Comment:
    IESG> 
    IESG> The end of Section 4 says:
    IESG> 
    IESG>    Any user of this resource record MUST carefully document their trust
    IESG>    model, and why the trust model of DNSSEC is appropriate, if that is
    IESG>    the secure channel used.
    IESG> 
    IESG> Does that really mean "any user"? Do we require end-users of our 
    IESG> specifications to generate documentation these days? If this is
    IESG> instead referring to derivate specifications or IETF-shepherded
    IESG> operational models based on these RRs, it should say so explicitly
    IESG> here. 

now reads:

   Any derivative standard that makes use 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.

    IESG> Nit: Should we encourage/require people who use xml2rfc to use the
    IESG> &lt;?rfc  
    IESG> compact="yes"?> directive? The amount of whitespace that is
    IESG> generated otherwise is a little bothersome.

  Didn't know about it.
  Hmm. My version doesn't have that. I will look later, when online.

    IESG> Bert Wijnen:

    IESG> Bigger issue:
    IESG> 
    IESG> - The examples use the reverse DNS records to convey IPSECKEY record.
    IESG> Does this have some unstated assumptions about the deployment of
    IESG> IPSECKEY (e.g., to be usable, the participating nodes should record
    IESG> the RRs in reverse records), or is this just a coincidence?
    IESG> I note that the document does not discuss the deployment at all, but
    IESG> that is probably intentional.
    IESG> 
    IESG> If there is no connection to the reverse records, I'd suggest
    IESG> rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com
    IESG> IN IPSECKEY ..."; if there is a requirement for reverse records, this
    IESG> issue needs to be explicitly discussed.. DNS deployment folks might
    IESG> have something to say about that :-)

  Chairs. Reverse is clearly in scope here.
  Can you discuss with Bert?

    IESG> Nits:
    IESG> 
    IESG> - Reorder sections 2.3 and 2.4 to be in the saem order as the fields.

  Done.

    IESG> - Replace the references to RFC1886 with RFC3596.

  Done.

    IESG> - Add IPR section

  Done.

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

  Any suggestions? 

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

  upper-case what? "IPsec"? the whole thing?
  I'll ask Bert directly.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Sam Weiler <[email-masked]>
Date: Tue, 16 Dec 2003 20:34:42 -0800 (PST)

> is really putting a higher standard on this record than there was in 2535.

2535 was also nearly unreadable.  Perhaps we should hold ourselves to
a higher standard. 

I don't think Thomas was asking us to codify anything -- he was asking
for explanation.  Let's give it to him.

-- Sam

-