Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

From: Vladimír Čunát <[email-masked]>
Date: Tue, 5 May 2020 16:50:38 +0200

Hello, I'm still a bit skeptical.

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).  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.

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.  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?  As for large TLD zones, even in best
currently practical case the reduction seems by less than a half? 
(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.

--Vladimir

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 May 2020 00:06:41 -0400 (EDT)

On Tue, 5 May 2020, Vladimír Čunát wrote:

> 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

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.

> won't be logged, but I hope that wasn't a significant point.

Right. Anything without DNSSEC cannot be helped.

>  The draft
> 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

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.

> 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

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 11 May 2020 10:51:09 +0200

> add a DS for everyone. That becomes a very visible event.

If they lie to your resolver, they replace it for everyone sharing the
same cache (for TTL duration).  So you say that people should hope that
someone else will also obtain the same "forged" DS by chance (say,
thanks to caching) and log it?  Perhaps it is an improvement... but in
me personally such a setup would not inspire confidence.

Speaking of non-DHCP DNS servers, if their provider promises to do all
the DELEGATION_ONLY validation *and* logging (and we authenticate their
servers, e.g. via TLS), that mode would actually make sense to me.  It's
a bit similar to trusting your DNS provider with DNSSEC validation and
not repeating it locally (though I personally prefer to do it again when
forwarding), but the tradeoff seems better here: security severity is
lower than bogus records and the logging surely won't be as cheap and
simple to deploy.

> append-only style transparency log using merckle trees.

Perhaps it's just me, but I'd expect the RFC to contain a plan on *what*
would be logged, in connection to the security assurances this should
get us (without most of the technical details on how to do the logging
exactly).  I think you mostly confirmed what would be logged below.

> Right. Anything without DNSSEC cannot be helped.

To be clear, I meant the proposed DELEGATION_ONLY flag, but that
sentence doesn't seem important.

> visa versa, or old-DS to new-DS). But that is outside the scope of

OK.  Nit: I'd expect that in practice most breakages would be
unintentional non-malicious errors, but they should still be only a tiny
fraction of all logged data (I hope).

> not do this and THUS you can log these things when you see them.

I was aware of that (the "zones without the bit" sentence).  I just
somehow thought the plan was to significantly reduce the amount of
logging *in* the DELEGATION_ONLY zones (in some "realistic" cases).  It
seems that I haven't missed any substantial savings in your plans -
thanks for confirmation, though I am a little disappointed, as it
doesn't seem easy to pull off to publicly log roughly the whole history
of most of signed records in DELEGATION_ONLY zones.

Still, perhaps it's not an issue.  Adding the flag on authoritative side
sounds trivial (except for initial rollover).  After it gets deployed
there in some notable zones, on resolver side the logging will bring
some security assurances to their clients, so I do see a chance that a
part of resolvers would be willing to do the work even if it's not so
little.

--Vladimir
(Knot Resolver)