Subject: [IPSECKEY] Comments on draft-ietf-ipseckey-rr-01.txt

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Apr 2003 04:06:39 +0200

,----
|    An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
|    record.
`----

Light-weight resolvers may prefer TSIG instead of DNSSEC.  Should this
scenario be mentioned?  E.g., add "or protected by TSIG".

,----
|    The algorithm field does not require any IANA action, as it is
|    inherited from DNS KEY algorithm values.
`----

The SIG RR also uses the same algorithm IANA registry.  It requires a
standards action to add a new algorithm.  An alternative would be to
fork the registry.

What about wildcard examples?  E.g.:

An example of a network that has delegated authority to the node with
the identity "corpgw.example.org".

*.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5 1
                    corpgw.example.org.
                    AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
                    Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
                    9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
                    49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
                    MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
                    cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
                    fejrfi1H )

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 16:43:47 -0400

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

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    Simon> ,----
    Simon> |    An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
    Simon> |    record.
    Simon> `----

    Simon> Light-weight resolvers may prefer TSIG instead of DNSSEC.  Should this
    Simon> scenario be mentioned?  E.g., add "or protected by TSIG".

  First, assuming that "DNSSEC = SIG only",
  Unless you are restricting this use scenario to within an enterprise (and 
even there, the scaling of TSIG is pretty dubious), I would expect that a
light-weight resolver will talk to a full resolver that does DNSSEC.

  As such, it seems to me that you are just using TSIG to get a trusted path
to a full resolver, and therefore this is a local issue. The records will
still traverse the wire with DNSSEC.

  Second, last I checked DNSSEC means SIG as well as TSIG.

    Simon> ,----
    Simon> |    The algorithm field does not require any IANA action, as it is
    Simon> |    inherited from DNS KEY algorithm values.
    Simon> `----

    Simon> The SIG RR also uses the same algorithm IANA registry.  It requires a
    Simon> standards action to add a new algorithm.  An alternative would be to
    Simon> fork the registry.

    Simon> What about wildcard examples?  E.g.:

    Simon> An example of a network that has delegated authority to the node with
    Simon> the identity "corpgw.example.org".

    Simon> *.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5 1
    Simon>                     corpgw.example.org.
    Simon>                     AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
    Simon>                     Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
    Simon>                     9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
    Simon>                     49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
    Simon>                     MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
    Simon>                     cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
    Simon>                     fejrfi1H )

  I can include this is there is some value in it.
  
  It has been suggested in private email that the gateway type field be taken
from the RR-type field, i.e:

     In section 2.4 you have created a new number space (gateway type) but
     have not mentioned this in the IANA considerations section.  Could you reuse
     the RR type number space for this? (eg. A(1) for IPv4 address, AAAA(28) for
     IPv6 address, PTR(12) for gateway name).  If this is a bad idea then you need
     to mention that you are creating a new number space. 

  I rather like this idea.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |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: Simon Josefsson <[email-masked]>
Date: Tue, 29 Apr 2003 23:46:39 +0200

>   First, assuming that "DNSSEC = SIG only",

That is my assumption.

>   Unless you are restricting this use scenario to within an
> enterprise (and even there, the scaling of TSIG is pretty dubious),
> I would expect that a light-weight resolver will talk to a full
> resolver that does DNSSEC.

Yes.

> still traverse the wire with DNSSEC.

Yes.

But from the point of view of the light-weight resolver, the IPSECKEY
is authenticated using TSIG and not DNSSEC.  I now understand that you
and the document may be talking about it from the point of the server,
but this is not clear IMHO.

>   Second, last I checked DNSSEC means SIG as well as TSIG.

RFC 2535 (DNSSEC) do not mention TSIG.  RFC 2845 (TSIG) do not update
RFC 2535.  The RFC 2535bis documents do not talk about DNSSEC as
including anything beyond what RFC 2535bis defines.  The introduction
document of RFC 2535bis further says (see below) that DNSSEC by itself
is not enough, and that TSIG and other channel security approaches are
often needed.  To me this implies that TSIG is not considered part of
DNSSEC.  If my assumption is wrong, I believe the DNSSEC specification
rewrite should adopt the new definition.

   DNSSEC, by itself, is not enough to protect the integrity of an
   entire zone during zone transfer operations, since even a signed zone
   contains some unsigned data, so zone maintenance operations will
   require some additional mechanisms (most likely some form of channel
   security, such as TSIG, SIG(0), or IPsec).

>   I can include this is there is some value in it.

The value I see is that it makes it clear that the wildcard usage
model was considered, and isn't an abuse of the standard, or
deprecated in any way.  An example isn't required, but I think at
least mentioning wildcard adresses would be useful.

-