On Tue, Apr 14, 2020, 6:16 PM Wes Hardaker <wjh...@hardakers.net> wrote:
> Ben Schwartz <bemasc=40google....@dmarc.ietf.org> writes: > > > If I understand correctly, the Powerbind draft is designed to reduce > > the amount of data that must be logged in order to verify appropriate > > use of a DNSKEY "K" for a delegation-only zone. I'm trying to compare > > the amount of logging required with and without Powerbind. > > > > Here's my current best guess: > > - With Powerbind, we need to log all DS records (to detect replacement) > and > > NSEC and NSEC3 records (to detect repudiation) that are signed by K, > along with > > their RRSIGs. Resolvers would reject any other records signed by K. > > - Without Powerbind, we need to log any record signed by K that is not > on the > > apex, along with its RRSIG. > > > > But for a delegation-only zone, aren't these the same set? What else > would a > > delegation-only zone be signing beyond the apex, other than DS, NSEC, and > > NSEC3? > > The point of powerbind is to specifically state "I'm delegation only". > Without knowledge of that, you end up having to log everything, per your > own conclusion, because there is no way to know if its a delegation-only > zone. I'm still not able to understand this. Suppose nic.footld puts a statement for humans on their website that says ".footld promises to be delegation-only". Then a log operator and its contributors can simply log everything signed by .footld's key, which should only be delegations. If anything other than a delegation shows up in the log, that is an obvious breach of the commitment. If a customer of .footld sees a delegation in the log that doesn't match their DNSKEY, they can raise a stink. This is without Powerbind. How does Powerbind make this better? As the first sentence in the abstract says "This document > introduces a new DNSKEY flag called DELEGATION_ONLY that indicates that > the particular zone will never sign zone data across a label.". IE, the > whole point is to communicate that a zone is such a zone. > This seems like it can easily be communicated just to humans, manually enabling logging for each zone of interest. Since only the TLDs and similar zones are really of any interest for logging, manually maintaining a list of zones to log is not difficult. Certificate Transparency operators similarly maintain lists of approved CAs whose certificates are permitted in their log. A curated list of this kind is required regardless; otherwise a hostile or buggy zone could spam the log with records. I still don't see why we need a machine-readable label to tell the logs that a zone is delegation-only, but if we do need one, we can have it without changing the behavior of recursive resolvers, and without needing to place anything in the parent (i.e. root) zone. What am I missing? -- > Wes Hardaker > USC/ISI >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
