On Thu, 30 Jul 2020, Ben Schwartz wrote:
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.
I would love to see some more description of these attacks in the draft.
I'm a bit confused that you think describing that in more detail helps.
We are talking about fairly simple records like the .ca zone publishing:
nohats.ca IN DS blob + RRSIG(key of .ca)
nohats.ca IN NS ns0.nohats.ca.
ns0.nohats.ca IN A 193.110.157.101
while also (targetted per victim or within a certain time frame) publishing:
_443._tcp.nohats.ca IN TLSA blob + RRSIG(key of .ca)
www.nohats.ca IN A <malicious IP> + RRSIG(key of
.ca)
nohats.ca IN MX 0 tapbox.ca. + RRSIG(key of .ca)
But I can add this if you feel it helps.
Does the targeted attack still> apply if the recursive resolver does QNAME
minimization?
It is unrelated to query minimalization, other than that targetted
attacks in response to specific queriers is harder.
From the current text, I'm having trouble understanding why it matters whether
the attacker has to
generate a fake child zone or not (in the absence of transparency).
The attacker could do the above (or even just present glue pretending
the nohats.ca is unsigned, thereby leaving out cryptographic traces).
If it is forced to generate a new DS for his attack to succeed, and they
are forced to publish this at large (eg because query minimalization)
then any monitoring of DS records will get them caught.
My "null hypothesis" throughout is that
1. zone owners can simply tell me their delegation policy if I email them to
ask, and
This does not scale and cannot be used to automate behaviour of DNS
servers in marking malicious responses as bogus or not.
2. participation in a logging scheme would require manual review and approval
anyway, because
delegation-only zones could still be inappropriate to log, either because they
have privacy concerns or
because they would spam the logs.
I think you are confused about transparency. The zone owner does not do
any kind of submittion to a CT log. Instead you monitor your own or
people at large monitor the domains they know or care about or find via
recursive query logs to keep a list of when its DS records have changed.
This requires no permission of the zone owner and does not involve any
agreement about whether producing DS record logs is "appropriate" or
not.
for a stronger case. Perhaps we can make logging opt-in part of the flag
definition? Or perhaps we can
signal it by the use of NSEC instead of NSEC3?
I don't see this being relevant. Also NSEC vs NSEC3 has different
hardware requirements and unrelated privacy considerations.
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.
But if the parent zone is delegation-only, then there won't be anything else to
log except in case of
violation, so these two logs are normally the same size.
You need to have that bit that TELLS you the zone is delegation-only
without involving humans, management of humans and management of TLD
data, update management policies, etc.
Yes, once you have that bit, the transparency log is reduced to the
violation cases, although you could not boter with logging the futile
attempts that would result in the DNS server dropping the data as bogus
anyway (although you might want it as proof that their DNSSEC key was
used abnormally)
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.
But how would such a signature come to exist, if ".ca" is a defacto
delegation-only zone?
While we at IETF and ICANN might have confidence that the root key or
some TLD keys will never be abused, the fact that these zones have the
power to use these keys for these kind of actions is what some very
vocal people in the infosec community keep hammering on as why you
cannot trust DNSSEC. This bit is specifically meant to increase that
trust.
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.
The draft says that universal logging "would require zone owners to expose all
their zone data ... thereby
introducing privacy implications". This seems to apply whether or not the zone
is delegation-only, so DNS
resolvers would be violating this proposed privacy principle unless the zone
somehow indicates that it
opts in to logging.
That statement applied to when we do not have this bit and we would want
to ensure no queries every violated the implicit delegation-only role.
Again there is no "submission" of zone data to a log anywhere in this
system by the authoritative zone operator. I will talk to Wes about
changing this text.
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.
If you move IP addresses without wiping your DNS cache, your cached DNS entries
become a supercookie by
which a distant server can reidentify you across the network.
That is why you use prefetching and ideally the resolver you are using
also uses prefetching, so that hot data (eg data that is regularly
queried for while it is still in the cache) is pre-fetched before
expiry. And no direct IP link exists between you and the auth server.
I think supercookies would be easier to do if I'm forced to re-query
everything I have all the time.
As such, I've been told that the best
practice for privacy is to bind the cache to a single interface and IP. I
would love to see a draft on
this topic, especially if you think this is actually not the best behavior for
privacy.
I don't think it is.
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.
In case it isn't clear, the concern here is about incorrect network
localization of DNS responses. This
is particularly important when using CDN nodes that are _inside_ an ISP, and
are intended for (or perhaps
even restricted to) serving that ISP's customers. However, it's true that this
is primarily about small
performance gains.
While that could be important and nice to have for my TV or playstation,
I'm not concerned with that for my phone or laptop. Especially since my
mobile devices already VPN across the planet, and are often at
coffeeshops and hotels where I wish my only problem was a 20ms delay.
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.
Yes, as I noted, this mechanism can deter this attack, but it cannot prevent it.
Nothing can prevent a parent from repurposing a child. It is inherent in
the DNS hierarchy. It's a small price to pay for being able to recover
your domain via legal proceedings, or from losing your private keys,
which is true for all "decentralized DNS" proposals.
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.
Yes, but nothing in the draft mentions this ...
We can add a note to say that anyone in your path can reroute packets to
their own network, thereby pretending to be any target IP address you
have, and as such, there is little value in preventing this takeover
at the DNS layer. I guess we could add that but then also need to talk
about on-path vs off-path attackers. I personally feel that is getting
rather out of scope for the draft.
nor its converse, that the draft only prevents targeted
attacks in use cases that already mandate DNSSEC.
I don't talk about DNS without DNSSEC. Without DNSSEC, you are running a
flawed vulnerable version of DNS. One of the largest mistakes of the
IETF has been that it has been so afraid of stating this, that it has
actually given people reason to think no-DNSSEC is a viable
"alternative". It's like trying to secure telnet because you don't like
ssh.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
