On Tue, 5 May 2020, Vladimír Čunát wrote:
1. Validation without logging. At the end of 3.1 you claim that mode is still useful. When I focus on intentional attacks, signing a malicious DS seems among the easiest ones, and that can't be detected without the attacked machine doing logging (the DS might be served to specific targets only).
Serving to specific targets is getting harder and harder, because we see more and more people defaulting to not use their DHCP obtained DNS server. And when picking another non-local server, DoH or DoT is preventing man in the middles from replacing DS records in responses. So they would either have to publicly replace the DS for everyone, or add a DS for everyone. That becomes a very visible event.
Consequently I'm doubtful about implementing and deploying such a "half-secure" approach in validators, especially as the RFC draft feels very hazy about the way logging might be done.
This draft is not trying to specify the DNSSEC logging. But I described things in earlier messages already. The way we had our experimental logging done with Linus Nordberg, is that we used dnssec-chains (RFC 7901) as the record format for the DNS data, wrapped in the regular append-only style transparency log using merckle trees.
2. Amount of logging. The draft implies it would allow to very significantly decrease the amount of data that needs to be logged. Zones without the bit perhaps won't be logged, but I hope that wasn't a significant point.
Right. Anything without DNSSEC cannot be helped.
The draft doesn't explicitly say what would be logged; my conclusion for zones using this bit is that "we" would need basically any authoritative (i.e. signed) data except for NSEC* records that have DS bit and miss opt-out bit. Am I missing something?
You would need to log the DS, and possibly log the denial of existence of the DS record. If the delegation-only bit it set, you can further log anything that should not have been signed but was signed, so any records outside of the apex that are signed. But this data is already dropped by supporting validators as BOGUS, so those hooks could be used for logging it. It should not be common. As soon as you see any of this, the zone is basically malicious and a public inquery should be started. As for opt-out, again zones without DNSSEC cannot be helped. Zones with DNSSEC, you log the DS and the denial of existence of DS. When to log this is a bit similar to the CT gossip protocol that was proposed. You log things when you see a modification (no-DS to DS or visa versa, or old-DS to new-DS). But that is outside the scope of this draft.
As for large TLD zones, even in best currently practical case the reduction seems by less than a half?
You are missing the point that currently resolvers cannot determine if a TLD is delegation-only. For example, if you assume all TLDs are delegation-only, you break things, such as .de where registrations can be done without NS record, straight signed by the .de key. The point of the DNSKEY DELEGATION_ONLY flag is to indicate that yes this zone does not do this and THUS you can log these things when you see them.
(missing DS bits in about half delegations) I expect that the whole trust chains to the logged records are also needed, so that the logger can prove they haven't forged the records.
Yes, you log an RFC 7901 chain from the root to the record in question you want to see logged. Not only to prevent the logger from lying, but also to proof you have the top-most offender in the chain. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
