The draft says zone digest is not for protecting zone transmition. IMHO,
the treat model is  MITM attack by malicious editing on on-disk data (NS
and glue especially) and server the new zone to end user. DNS digest
intends to enable end users (resolvers)  automatically detect the
modifation ( and drop the zone?).

Davey

On Fri, 27 Jul 2018 at 11:00, Shumon Huque <shu...@gmail.com> wrote:

> On Thu, Jul 26, 2018 at 10:53 PM Steve Crocker <st...@shinkuro.com> wrote:
>
>> Let me play Candide and stumble into this naively.  If we’re imagining
>> very wide spread distribution of the root zone, say 100,000 or 1,000,000
>> local copies distributed twice a day, I would expect the evolution of a set
>> of trusted sources and the use of some existing secure transport protocol
>> to protect the transmission.  No new protocol or data types, just a way of
>> finding the address of one more trusted sources.  And the existing set of
>> root servers seems like a perfectly good set of trusted sources.
>>
>
> Hi Steve,
>
> Yes, I've made precisely the same argument previously in this very thread:
>
> https://www.ietf.org/mail-archive/web/dnsop/current/msg23094.html
>
> "> 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."
>
> At the moment, some WG members feel that full zone signature is more
> secure and needed. I'm not convinced (on the "needed"), but don't feel
> strongly enough to be opposed either.
>
> Shumon.
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to