On Thu, 30 Jul 2020, Petr Špaček wrote:
It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having
description of "DNSSEC Trasparency" mechanism available.
I do not believe that is correct. The first and foremost purpose is for
the bit to signal the parent zone's behaviour in a public way that
prevents targeted / coerced attacks from the parent. This allows
policy violations to be rejected even if these violating DNS answers
are DNSSEC signed.
Secondary, it eases the transparency logging. If it is clearer for
us to leave out the DNSSEC Transparency parts, that can certainly
be done, but I will try to provide text to Ben's and others to
clarify this latter part.
On 29. 07. 20 21:54, Ben Schwartz wrote:
Exposing such targeted attacks requires a transparency audit
infrastructure similar to what is deployed for PKIX ([RFC6962]).
However, a DNSSEC version would need to log significantly more data,
as all signed DNS data used by a DNSKEY must be recorded in order to
prove that data signed by a parent zone's DNSKEY was out of expected
policy. The very distributed nature of the DNS combined with the
typically frequent zone resigning rate makes such transparency logs
prohibitively expensive and nearly impossible to operate.
How does this draft alter that cost? For delegation-only zones that are in
compliance, it seems like the cost is not changed. Presumably violations will
be rare, so they won't contribute significantly to the cost.
You can only be a "delegation-only zone in compliance" if you publish
this new DNSKEY flag. Without this flag there is no way to know the
zone's policy. This is what is often described as the Public Suffix
list/problem.
One you know a zone is delegation only, the only way this zone can still
try to violate its own policy is to replace the child delegation with
its own. Therefor, you only need to log DS records that will show you
there is a child zone change. And resolvers can drop any Answers DNSSEC
signed outside the apex as bogus. Therefor, the parent won't even try
to do this and we dont have to log all its queries.
Without this bit, even if we know ".ca" is defacto a delegation only
zone, we have no mechanism to drop records violating this policy without
maintaining a public suffix list type within the resolver or using some
RBL type queries to more dynamically determine the delegation-only
aspect. So now we need to log things like _443._tcp.nohats.ca. IN TLSA
records if signed by something higher than nohats.ca because we can
no longer declare such records as "harmlessly dropped as bogus" and
we simply cannot tell if the record is legitimately signed or not.
Additionally, it would require zone owners to expose all their zone
data to any public log operators, thereby introducing privacy
implications and exposing all relevant DNS data to a public archive.
I don't understand how this flag would alter that exposure. If my zone is
already delegation-only, how does adding this flag improve privacy?
Your zone is not "delegation only" if you have no automated way of
declaring it as such that is accepted by DNS resolvers all over the
world. See Public Suffix issues.
At the time of this writing, the list of entries in the
public suffix list contains over 8800 entries as well, with 73 wild-
card entries (prefixed with a "*") indicating that all of their
(unknown number of) children are public registration points. In the
absence of an interoperable mechanism (like this draft provides), it
is infeasible that a validating resolver or auditing log could know
which of these zones are delegation-only without individual policy
statements from each of them.
Marking a zone delegation-only doesn't imply that it is suitable for logging,
so wouldn't participation in any logging scheme require an individual policy
statement anyway?
Logging is not done by the publishers (zone owner) like in CT. Logging
would be done by DNS resolvers in some privacy preserving shared method.
Finally, a DELEGATION_ONLY flagged DNSKEY for
the root zone cannot be overridden easily, as it would require a
trust anchor update in all validating resolvers.
The preceding sentences deal with the lingering "false child key" problem,
which still applies here, so I don't understand the relevance of this sentence.
I'll clarify that in the next version.
I also had some thoughts on the Security Considerations:
Care should be taken by resolvers to not
unnecessarily empty their cache. This is specifically important for
roaming clients that re-connect frequently to different wireless or
mobile data networks.
I believe this advice is counter to best practices for mobile clients for both
performance and privacy reasons. See e.g. http://dnscookie.com/.
Performance and privacy cannot always go hand in hand together. As for
privacy, I don't understand your argument. When my laptop fires up in a
coffee shop on an empty cache, you will see:
- possibly priming queries and TLD queries
- my firefox tabs reloading/updating causing queries to:
* bugzilla.redhat.com
* jabber.org
* github.com queries
* testing.libreswan.org
* datatracker.ietf.org
- Me doing som work will trigger:
* A/AAAA and SSHFP queries for *.nohats.ca
On an empty DNS cache, I'm quite literally broadcasting the largest DNS
fingerprint possible to identify my. My only change at hiding is to have
a local DNS cache. The last thing I care about is 20ms speedup for some
web page content - the ones who care about those 20ms are the ad auction
participants, not me.
Also, I think it's worth mentioning that "delegation-only" zones can still deny
the existence of a DS for the child (if the child was signed to begin with), and then
generate deep unsigned records for the child. This limits the direct impact of this flag
to cases where DNSSEC is mandatory. (Logging might be able to deter this attack,
assuming NSEC records are logged.)
No they cannot generate "deep unsigned records". Their zone is signed,
so if they are not adding a zone cut / delegation, then they have to sign
it or else DNSSEC validating resolvers will drop those queries as bogus
(missing RRSIG).
Yes they can deny the existence of a child, but that too needs a
signed record of non-existence (NSEC or NSEC3) which would be logged by
transparancy clients logging DS or proof of non-existence of DS.
If you are talking about TLD's that are not dnssec signed, there
is nothing we can do to help those at this point. Any ISP used by me
at the coffeeshop can already send forged A/AAAA records. But that is
pretty harmless, as that has the same impact as your ISP just performing
NAT on your packets or routing your packets to their stolen IP based
networks. The power to change A/AAAA is not what anyone is really trying
to prevent. The prevention is mostly for records with public keys of
fingerprints, such as TLSA, SSHFP, IPSECKEY, eSNI and what not. And none
of those records should ever be used without being protected by DNSSEC
to begin with.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
