On Thu, Sep 10, 2020 at 2:33 PM Stephane Bortzmeyer <[email protected]> wrote: > > On Mon, Aug 31, 2020 at 09:05:41AM -0700, > The IESG <[email protected]> wrote > a message of 51 lines which said: > > > The IESG has received a request from the Domain Name System Operations WG > > (dnsop) to consider the following document: - 'Message Digest for DNS Zones' > > <draft-ietf-dnsop-dns-zone-digest-09.txt> as Proposed Standard > > This is not really part of the Last Call (I have no problem with the > document in its current form), it's more about two "philosophical" > questions I have about zone digests. > > One is small: the draft claims "a name server loading saved zone data > upon restart cannot guarantee that the on-disk data has not been > modified". This argument seems weak. Can we really imagine attacks > where the attacker can modify the zone file on the disk, but cannot > modify the verifier, for instance its code, or its trust anchors?
Ah, this wasn't intended to deal with *attacks*, but rather accidental zone corruption; for example, copying the zone file to an (almost) full disk, and ending up with a truncated zonefile (this has bitten a few TLD/ccTLDs), or a transfer dying midway through a copy, etc. > > The other is more complicated. The draft says "Unfortunately, the > protections [TLS, SSH, etc] provided by these channel security > techniques are (in practice) ephemeral and are not retained after the > data transfer is complete. [they] not provide any methods to verify > data that is read after transmission is complete." In the DNSSEC cas, > zone digest provide such a method but only for a time. Once the keys > are rolled over, the verification is no longer possible. Since most > (all?) DNSSEC tools assume they can delete a key once the RRSIG which > use it have been removed from all caches, you can have a zone file > whose signatures are still valid (not expired) but the DS and/or keys > are no longer available online. Unless I'm wrong, this limit is not > mentioned. (Not sure it is important in practice, as I said, it is > more a philosophical question.) Hmmmm. Yes, I suspect that you are right, and that this isn't mentioned. Do you have any suggested text? If so, could you send it to the IETF LC so it gets captured? W > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
