On Wed, 29 Jul 2020, Ben Schwartz wrote:
I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to
make sure that the draft isn't overstating the achievable benefits. To that
end, I have some
questions about the text of the -01 draft.
(I recognize that these are issues I've raised before, but I still haven't
gotten answers that I understand.)
Assuming the claims are correct, I think they need some clarifications for
naive readers like myself (and possibly deduplication, since some claims are
repeated in
different sections).
> 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.
Whether or not they are in compliance does not alter the cost. Once the
delegation-only bit it set, only the DS/DNSKEY records need to be logged
instead of all data signed with the parental key. Any "deep signed"
data by the parental key will be rejected automatically by resolvers
supporting this, so there is no requirement to log these.
It might be that the occurance of this deep signed data is rare, but
without the delegation-only flag, you cannot determine if such deep
signed data is legitimate or not. That is what the delegation-only flag
indicates.
Presumably violations will be rare, so they won't contribute significantly to
the cost.
I don't know how rare this is, but for example if it became known that
this logging was happening (due to not having delegation-only) then
atttackers could spam the DNS transparency log with deep signed data
that would have to be logged. Attackers could also try to hide and
seek via CNAMEs. All of these would need to get logged. Versus only
logging DS/DNSKEY.
> 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?
I have removed this section, as with our current DNS model, all queries
are seen anyway by some people (like Paul Vixie et all)
> 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?
DNS audit logs could decide to only log parents that are
delegation-only. To protect themselves and to advocate for
parents adding this extra transparency / security to their zone.
> 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 agree. I removed the sentence
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/.
I read up on that page but the information there is not very detailed. I
_think_ that forgetting a cached entry before its TTL is up, would
actually expire this dnscookie faster? So you would become less
trackable?
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.)
Any zones under the (signed) parent that are not signed are completely
untrustworthy anyway. We cannot help these zones. Any of their data
can be spoofed by anyone in the forwarding chain.
A rogue parent changing or modifying the DS set cannot be prevented,
but can only be logged. When we mention DS logging, that includes
the logging of the absence of a DS record. So that includes any
switching of the zone from secure <-> insecure.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
