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

[Vladimír Čunát <[e-mail]>]

On 5/7/20 6:06 AM, Paul Wouters wrote:
> On Tue, 5 May 2020, Vladimír Čunát wrote:
>> 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).
>
> 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.

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.


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

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.


>> 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.
>
> Right. Anything without DNSSEC cannot be helped.

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


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

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


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

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)