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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
