[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Mon, 16 September 2019 15:35 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 6EF7112012A for <dnsop@ietfa.amsl.com>; Mon, 16 Sep 2019 08:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 ozAH_Do_yqMd for <dnsop@ietfa.amsl.com>; Mon, 16 Sep 2019 08:35:57 -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 C24C0120052 for <dnsop@ietf.org>; Mon, 16 Sep 2019 08:35:56 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b1f6:a834:75b9:fc62] (unknown [IPv6:2001:1488:fffe:6:b1f6:a834:75b9:fc62]) by mail.nic.cz (Postfix) with ESMTPSA id F1BD3140F0B for <dnsop@ietf.org>; Mon, 16 Sep 2019 17:35:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1568648155; bh=U41YbakdbjO3BimX75+zauDYeSScWVskl8GKMQclLDQ=; h=From:To:Date; b=nl41b5p6ivjLSzyuwh6A4Xz6+l1h0VT1/t8vRaUJeeHU3NluRGIYBW+lSYovJPyUE /y9W8YLiv/CPsN5gmhm+zrdA/vGrrZ4TN798pVObxvR/jEztUWPg2m3rGtStzUOh1a j18S0JJVykxqT0sCSxiGQDE9tFy6kO8UWUteZp5U=
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==
To: dnsop@ietf.org
Message-ID: <73a85a8f-19b0-3d57-e2e9-d5117ab1e227@nic.cz>
Date: Mon, 16 Sep 2019 17:35:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BXf8V1WN2-OvNAHeroP6pDccTtQ>
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.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: Mon, 16 Sep 2019 15:36:00 -0000

The following comments are only loosely related to multiple threads
here, so let me post them in a single bunch.

On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.2 (code 2), may warrant more guidance on when this is
> appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
> being unsupported, provided the same holds for the DS RRset.  So,
> while I see a use-case for code 3 (all DS unsupported, perhaps to
> signal why the AD bit is not set, despite the non-empty DS RRset),
> I don't understand when one would use code 2.

I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
algorithms being unsupported, and it actually makes me wonder how to
exactly write the resolver code that would set this pair.  For
validation I need at least one usable DS RR, i.e. one where *both* the
DS and DNSKEY algorithms are supported.  I believe that's the exact
condition to be able to extend the trust chain. (and that's how I
implemented it for Knot Resolver)  It may theoretically even happen that
there is a supported DS algorithm and a supported DNSKEY algorithm but
never paired together in the DS RRset - IIRC it's not perfectly correct
to generate such an RRset but that's probably not something a validator
should care for.


On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.8 [...]
>
>    So just *an* expired signature is not really a problem provided
>    another signature for the same RRset is not expired.  So I think
>    the text could more clearly read "but *all* signatures for an
>    RRset in the validation chain expired", or some such.

Nitpick: *if* we were diving into such details... each RRSIG might fail
for a different reason, for example.  That's the general problem with
providing reasons for validation failures: validation is defined in the
sense that you (may) succeed when at least one of various ways
succeeds.  A failure could typically be fixed by multiple different ways
(EDE codes).  Still, I'd hope that in most real-life cases the
implementations can "correctly" guess what's wrong.


On 9/13/19 10:01 PM, Tony Finch wrote:
> 3.5.  Extended DNS Error Code 4 - Forged Answer
> 3.16.  Extended DNS Error Code 15 - Blocked
> 3.17.  Extended DNS Error Code 16 - Censored
> 3.19.  Extended DNS Error Code 18 - Filtered
>
> I don't understand the shades of meaning that these are supposed to
> distinguish.
>
> wrt "filtered", the description implies vaguely RPZ flavoured filtering,
> but it mentions a REFUSED RCODE which isn't what a sensible implementation
> would use for that purpose, so I am more confused.

With the switch to codes not specific to RCODE, I think some more
code-merging would be nice, in particular 3+19: stale (NXDOMAIN)
answer.  Perhaps also drop "4 forged" in favor of the other options?
(blocked, censored, if I understand the definitions)  Or is "forged"
meant for cases like the special top-level invalid. zone?


I think the current -09 "Security considerations" section is a bit
misleading.  It talks about the extended error being unauthenticated in
case of validation failure, but the current SERVFAIL is the very same
and that part is the more important bit (noticed by Paul Hoffman, too). 
With extended errors we only get more information of the same
authenticity.  In general, clients that don't want to validate
themselves can also choose a middle ground where they trust the resolver
and secure their link to it (typically by DoT or DoH).

Also, *if* the EDE codes will only be used for [diagnostics], I don't
really understand why have any "Security considerations" at all. 
Perhaps I'm just confused about the overall intention.
[diagnostics]
https://mailarchive.ietf.org/arch/msg/dnsop/rbkGvMH-vG-P5GHUx06-LRWYRgM


--Vladimir