On Thu, Jun 21, 2018 at 11:56 AM Wessels, Duane <dwessels= [email protected]> wrote:
> > The problem I'm seeking to solve is somewhat different, and its probably > not clearly stated in the draft so I will add some text to rectify that. > > I'm not trying to solve the problem that SIG(0), SIG(AXFR), or TLS > addresses > -- that you're talking to the right server and that data wasn't modified > in transit. > > My goal is to ensure that when you receive a zone file -- however you > receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get the > data that the zone publisher actually published. > I can't argue with that goal (and yes, you should probably clarify it in the draft). The question for me is what are the use cases for this protocol enhancement, and is this the only way to satisfy those use cases? In my mind, the main compelling use case is secure distribution of the root zone at scale to anyone on the Internet. For that, I'd bet that many consumers would be quite okay with a channel security mechanism to a "trusted" root zone operator, whatever that mechanism is (TSIG, SIG(0), TLS, HTTPS, etc) as long as it could be done efficiently and at scale. A full zone signature from the zone publisher/signer is ultimately more secure of course. But if the security model is satisfied by trust in RSOs, then that isn't needed. The normal case of distributing a zone securely to all your authoritative server operators, I believe, is adequately satisfied today by zone transfers authenticated by pre-configured static TSIG keys provisioned between the authorized parties. Do you see the full zone signature as a replacement for this scenario too? (There are many zones much larger and more frequently updated than the root zone, for which I believe the computational cost of this is too prohibitive). As noted earlier, out of band verification of the full zone using an integrated signature that does not rely on an external keying infrastructure, is also a plausible use case. I'm just wondering if it has a compelling need. Anyway, not trying to derail this effort, just asking questions. On balance, I think I support this draft. Shumon.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
