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

Vladimír Čunát <> Mon, 11 May 2020 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F378A3A092D for <>; Mon, 11 May 2020 01:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dppHqEhtyZNg for <>; Mon, 11 May 2020 01:51:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25FE93A092C for <>; Mon, 11 May 2020 01:51:13 -0700 (PDT)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by (Postfix) with ESMTPSA id 16B4A140C67; Mon, 11 May 2020 10:51:10 +0200 (CEST)
To: Paul Wouters <>,
References: <> <> <>
From: Vladimír Čunát <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA==
Message-ID: <>
Date: Mon, 11 May 2020 10:51:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 May 2020 08:51:19 -0000

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

(Knot Resolver)