Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Paul Vixie <[e-mail]>]

Paul Vixie wrote:
> 
> Viktor Dukhovni wrote:
>> ...
>>
>> What's attractive here, is that real resolvers (local to the same
>> device) already have the requisite feature-set, and there's no need
>> to augment stub resolvers with features already handled by local
>> recursive resolvers.  If a device is too dumb to run a separate
>> resolver process, I don't expect it'll have a trustworthy DNSSEC
>> implementation in its stub resolver.
> 
> trusting a dns response's AD bit to tell you that the responder has done
> careful signature checking all the way back to a trust anchor you have
> confidence in, doesn't fit the hotel or coffee shop scenario -- you do
> not want your hotel or coffee shop in the role of making a secure
> introduction between you and your bank, for example.

since the hotel is unlikely to transmit on an interface that's local to
the same device, let me amend this as follows:

trusting the AD bit just because the packet appears to have been
generated locally is a dangerous model. if the specification requires
that the stub have explicit and non-default cause for confidence in the
sender's identity and fidelity, then there's no way to test for this,
and since there's no way to test for it, it won't be widely implemented.
time to market is the primary driver for a product or service's lifetime
revenue envelope, and any requirement that won't face acceptance and/or
interoperability testing, WILL be left out.

the thing you CAN test for is whether the signatures are valid. which is
why first dan kaminsky and later paul wouters wanted to send the full
signature chain. perhaps that can be merged in here: if the stub
resolver can see the full signature chain and do its own validation,
then it ought to believe that the data is authentic. this would put the
burden on system vendors to put signature chain gathering/expansion into
their on-device RDNS or DNS Proxy, so that local stubs saw same.

-- 
P Vixie