[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:

>>>>>> "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",

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.

>   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.

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).

>     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.

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.

-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.