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

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPq7kAYqHRg3pndX9AQEBGQQA65k88E4QGHJi/8zAkjUpV7NSoY1ROEXD
kTM0Ilx8JJNpNbtwb6MzC8s4lvBwYtvg5+ttXsWEXsz7c04wFkMNambVzkA1REB7
yQ3nYQ/qSg4065owgB/BL4xnZZu21Zgz6NN4amUIizAu/pl6TxNmu+1UCvVpME1a
ynPlaXv1ZTQ=
=+TOT
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.