Re: [DNSOP] changes to extended errors based on your comments

Shane Kerr <shane@time-travellers.org> Mon, 26 August 2019 21:53 UTC

Return-Path: <shane@time-travellers.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 61B7612011F for <dnsop@ietfa.amsl.com>; Mon, 26 Aug 2019 14:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 SAB6VOSSm_AD for <dnsop@ietfa.amsl.com>; Mon, 26 Aug 2019 14:53:52 -0700 (PDT)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (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 CD05212001A for <dnsop@ietf.org>; Mon, 26 Aug 2019 14:53:51 -0700 (PDT)
Received: from earth.zonnestelsel.tk ([2001:470:78c8:2::9]) by time-travellers.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <shane@time-travellers.org>) id 1i2Mvu-0007mB-E4 for dnsop@ietf.org; Mon, 26 Aug 2019 21:53:50 +0000
To: dnsop@ietf.org
References: <ybl36i9io38.fsf@w7.hardakers.net>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <fc305b72-adaa-0045-3e30-53e9457f9c1d@time-travellers.org>
Date: Mon, 26 Aug 2019 23:53:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <ybl36i9io38.fsf@w7.hardakers.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WpXNr-oHTjEQpsO8CUqAXkdS37I>
Subject: Re: [DNSOP] changes to extended errors based on your comments
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, 26 Aug 2019 21:53:53 -0000

Wes,

On 10/08/2019 07.30, Wes Hardaker wrote:

> 8.3.5 NOCHANGE Finally, I note that the suggestion of requiring that the sender have
> ------------------------------------------------------------------------------------
> 
>    some signal indicating that it is interested in extended errors was
>    not adopted. I don't insist on it, but I think it would be useful to
>    avoid bloating packets unnecessarily. It's a bit like the useless
>    additional section data that lots of servers insist on appending to
>    answers... why send something that will not be seen?
> 
>    OTOH I realize that having this information available may be useful
>    for humans debugging things, even if the sender does not ask for it.
> 
>    + Response: If there sufficient support, we'd certainly add it.  This
>      is primarily intended to be used for extreme cases and only when
>      problems/unusual are detected.  Most DNS messages won't contain EDE
>      options and when they do they'll likely fall below the DNSSEC
>      amplification factors that are out there.  We think the benefit of
>      including the extra information outweighs the problems with sending
>      it.  But we'd certainly love to hear more feedback from the
>      community to see if there is agreement one way or another here.

I guess on balance always having the information is the simplest 
approach. If there is a specific concern this can be changed.


> 8.3.6 NOCHANGE On the gripping hand, adding unasked-for information may have privacy
> ------------------------------------------------------------------------------------
> 
>    implications. Possibly adding a "Privacy Considerations" section would
>    be useful?
> 
>    + response: What would you like us to add to such a section?  The
>      question/answers section likely has most of the sensitive
>      information.  If you'd provide text to clarify your thinking, we'd
>      gladly include it.

I looked through RFC 6973 Section 7 - 
https://tools.ietf.org/html/rfc6973#section-7 - and didn't see anything 
that stuck out obviously to me.

Possibly the only real concern is with extra text. It currently reads:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators.

Quad9's proposal to include various helpful information like how 
dangerous a particular answer might be made me think that we should be 
careful not to leak information in this channel. For example, a response 
should not say something like, "daily query limit reached for account 
7452-54".

Possibly the description could be changed to something like:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators. Care should be
    take not to leak private information that an observer would not
    otherwise have access to, such as account numbers.

Cheers,

--
Shane