Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

Petr Špaček <pspacek@isc.org> Fri, 12 November 2021 13:24 UTC

Return-Path: <pspacek@isc.org>
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 C00E73A08F3; Fri, 12 Nov 2021 05:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level:
X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=UYc5Qa6B; dkim=pass (1024-bit key) header.d=isc.org header.b=IXCs4x05
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 nwqcitmS3R1E; Fri, 12 Nov 2021 05:24:33 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 1DB183A08FA; Fri, 12 Nov 2021 05:24:33 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 682FC433F33; Fri, 12 Nov 2021 13:24:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1636723470; bh=CSgSq16+PtEeWx40LYMYIz2a2DxHk/eOV+Mwkxb/5as=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=UYc5Qa6BrRS1SlApMUDoPPY3ORX2nRztYP0wOn5c7ZRD/hXLIQyHyT3DF5S0wE/EL qiWv6hffJ9rL/oe3zIB8H+A+We1Ftc6w/BIPCUQDHbPPpK9yaJzN8eK7SG1BEVp8sQ z7PzJo6A4kAY5+Eu1UWrPA8L/+FpzScuFBgRGmvo=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 57EB9F063FA; Fri, 12 Nov 2021 13:24:30 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 19E20F063F7; Fri, 12 Nov 2021 13:24:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 19E20F063F7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1636723470; bh=KVpGOWb6prp4Z+3Aga/0A+RuzjTwrBwrNuB17gBD2fw=; h=Message-ID:Date:MIME-Version:To:From; b=IXCs4x056XUKlveZeHU8+6+gfZz92+7Xq+W4Jy+nuOww2vxJ7YVfQ0JGebGw8NjHb WE5XKFU7V4Zq7hamLQ1h4FQSIdC8oGtyo0aVA4pLaxEVLmxbcCLDlTV8wJ2emHUyK5 67GVMhqQPLYbiHgHJQJ0yfEhmpqMqlITb6qFoxLk=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BT-seFFRDFLB; Fri, 12 Nov 2021 13:24:30 +0000 (UTC)
Received: from [192.168.0.157] (ip-86-49-254-49.net.upcbroadband.cz [86.49.254.49]) by zimbrang.isc.org (Postfix) with ESMTPSA id E9FDEF063F6; Fri, 12 Nov 2021 13:24:28 +0000 (UTC)
Message-ID: <ef4dcfc8-0208-af8d-24d5-99fe7e3edb56@isc.org>
Date: Fri, 12 Nov 2021 14:24:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: Manu Bretelle <chantr4@gmail.com>, Roy Arends <roy@dnss.ec>
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, Matt Larson <matt.larson@icann.org>
References: <8A09A0DF-D915-45AD-AD57-229641F19120@dnss.ec> <CAArYzrLDZrjR2b9nvaxDn8vScb5TYLd54JrFtoCoLmvqikVVOQ@mail.gmail.com>
From: Petr Špaček <pspacek@isc.org>
In-Reply-To: <CAArYzrLDZrjR2b9nvaxDn8vScb5TYLd54JrFtoCoLmvqikVVOQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1fsHqP34IB8E_Qlm23tOpnRsIlU>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting
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: Fri, 12 Nov 2021 13:24:38 -0000

On 12. 11. 21 7:42, Manu Bretelle wrote:
> Hi Roy,
> 
> I like the idea of an out-of-band error reporting and therefore I like 
> the proposition of this draft.
> 
> One of the things I have a hard time visualizing though is how this 
> could be used for more than reporting DNSSEC specific errors. With the 
> option not being signed in the first place, it does not seem that DNSSEC 
> is a requirement to be able to leverage this functionality, hence it 
> would be great to think how we can make this work for more than 
> DNSSEC-only errors.

E.g. it can conceivably report errors like "resolver had to fallback to 
Nth server because the first one we tried times out". Is that a 
sufficient example?


> As it is, the requirement for the EDNS0 option to be in the response, 
> while it does offer some properties such as controlling sampling rate…, 
> essentially will prevent any report of answers which are not properly 
> formatted in the first place, or never received like when a resolver is 
> not able to reach any authorities for a given name, when resolver start 
> falling back on staled data, and possibly in the future, failing to 
> reach over an advertised encrypted channel… There is likely value for an 
> authoritative resolver operator to be able to get report for those 
> issues too.

While I agree with the sentiment that reporting other issues would be 
also useful, I think that _for now_ we should keep the scope limited to 
situations which do not require any extra state in resolvers.

That is, reporting "no server is reachable" requires prior information 
stored or reachable somewhere else, which is IMHO order of magnitude 
more complex task. Let's get experience with simple error reporting 
first and only then move forward to more complex tasks...


> The title of the draft: "DNS Error Reporting" would let one believe that 
> it is a somewhat generic mechanism, but I don't think it is as is. 

I disagree here. It is a generic mechanism, see the first response 
paragraph in this e-mail.

> Actually, while DNSSEC is not named in the title/abstract, the examples 
> in the abstract are DNSSEC specific, the wording in the rest of the 
> document refers for the most part to "validating resolvers". Should this 
> be a "DNSSEC Error Reporting" draft? or a "DNS Error Reporting" draft, 
> but then the function of "validating" itself should be less emphasized? 
> While a validating resolver can report more type of errors than a 
> non-validating resolvers, validation is not a requirement to be able to 
> report.

Agreed, but I really don't feel the problem as severe. Would it be 
sufficient to add more examples of non-DNSSEC errors?


> On Tue, Nov 9, 2021 at 3:07 PM Roy Arends <roy@dnss.ec 
> <mailto:roy@dnss.ec>> wrote:
> 
>     Dear WG,
> 
>     Change 3) There as a lot of descriptive text what implementations
>     should and shouldn’t do, and what configurations should and
>     shouldn’t do. This was found to be overly descriptive and pedantic,
>     and has now been removed.
> 
> 
> I see that the security consideration about not reporting errors from an 
> encrypted channel (over a supposedly unencrypted channel) has been 
> removed. Wouldn’t it make sense to leave it in order to avoid leaking 
> traffic for queries that were not previously visible on the network? 
> Possibly requiring than an encrypted channel (equal or stronger, for 
> whatever definition that may be) is used to send such reports if needed? 
> This would also make sure the mechanism is going to work once the ADo* 
> mechanisms are ironed out.

AFAIK it was removed because the only things we could place there were 
extremely vague and probably not implementable anyway.

Reason: There is _no such thing_ as 1:1 mapping between client queries 
and outgoing answers, which makes it super hard to define anything sensible.

A simple example:

1. Client A asks for
login.secret.facebook.com
over plain UDP (and is now waiting for resolver's answer).

2. Resolver starts recursing and eventually sends query for 
secret.facebook.com NS over UDP (client sent query over plain UDP, 
right?). At this point the query was sent but answer was not received yet

3. Client B asks for
supersecretdomainnobodyshouldsee.secret.facebook.com
over TLS

4. Resolver deduplicates the query for secret.facebook.com NS, i.e. 
queries (1) and (3) are now waiting for the same packet - delegation 
from facebook.com to secret.facebook.com.

5. If this deduplicated query for secret.facebook.com NS failed and came 
back with error reporting option, what should the resolver do now? We 
have two clients waiting for it. Is the query considered "secret" or 
not? If the client B (packet in step 3.) arrived couple ms later it 
would not be secret?

In short: This way madness lies.

The only sane way to implement "never leak queries to plaintext" policy 
is to operate TLS-only resolver and do not permit non-TLS 
clients/queries. Then you can disable the error reporting feature 
completely ...


Having said that, we can have _some_ text in Security considerations 
section, but someone needs to write a sensible description - which I'm 
not capable of.

Have a great day.
Petr Špaček



> 
> Thanks,
> Manu
> 
> 
> 
>     There was a request to put the markdown version of the document in
>     GitHub. This has now been placed here:
>     https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting
>     <https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting>
> 
>     New version:
>     https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt
>     <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt>
>     Diffs:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01>
> 
>     Warm regards,
> 
>     Roy Arends