Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

[Paul Wouters <[e-mail]>]

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