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

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Tue, 05 May 2020 14:50 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5363A0882 for <dnsop@ietfa.amsl.com>; Tue, 5 May 2020 07:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMZDEZnnYdWN for <dnsop@ietfa.amsl.com>; Tue, 5 May 2020 07:50:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369383A0872 for <dnsop@ietf.org>; Tue, 5 May 2020 07:50:42 -0700 (PDT)
Received: from [192.168.6.18] (nat-45.starnet.cz [178.255.168.45]) by mail.nic.cz (Postfix) with ESMTPSA id 9B78613FB56 for <dnsop@ietf.org>; Tue, 5 May 2020 16:50:39 +0200 (CEST)
To: dnsop@ietf.org
References: <158828214716.7748.7938281376930754647@ietfa.amsl.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Autocrypt: addr=vladimir.cunat+ietf@nic.cz; 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: <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz>
Date: Tue, 5 May 2020 16:50:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <158828214716.7748.7938281376930754647@ietfa.amsl.com>
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: <https://mailarchive.ietf.org/arch/msg/dnsop/o-Fi1h1z77DhSRBehgzslhs86SE>
Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 14:50:53 -0000

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