Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

Shane Kerr <shane@time-travellers.org> Thu, 01 October 2015 10:12 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6901A1B28 for <dnsop@ietfa.amsl.com>; Thu, 1 Oct 2015 03:12:47 -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_HELO_PASS=-0.001] autolearn=ham
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 85_XP0LH2xAn for <dnsop@ietfa.amsl.com>; Thu, 1 Oct 2015 03:12:45 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4031A1B27 for <dnsop@ietf.org>; Thu, 1 Oct 2015 03:12:45 -0700 (PDT)
Received: from 143-245-128-083.dynamic.caiway.nl ([83.128.245.143] helo=casual) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1Zhaqv-000309-Dv; Thu, 01 Oct 2015 10:12:41 +0000
Date: Thu, 01 Oct 2015 10:12:41 +0000
From: Shane Kerr <shane@time-travellers.org>
To: Joe Abley <jabley@hopcount.ca>
Message-ID: <20151001101241.08ff8702@casual>
In-Reply-To: <2EB63978-61F4-4833-8433-FDEE77CD4D65@hopcount.ca>
References: <20150930190405.17300.40441.idtracker@ietfa.amsl.com> <20151001025833.GA51655@isc.org> <0F438B6C-4797-4250-ABCA-4C5AE1D5F232@hopcount.ca> <20151001050850.GA51763@isc.org> <2EB63978-61F4-4833-8433-FDEE77CD4D65@hopcount.ca>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/aLpOYg3edinGwK9xLMncfdxIyCo>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 01 Oct 2015 10:12:47 -0000

Joe and all,

On 2015-10-01 02:25-0400
"Joe Abley" <jabley@hopcount.ca> wrote:

> On 1 Oct 2015, at 1:08, Evan Hunt wrote:
> 
> > The disadvantages of pick-one-RRset that I can see are 1) more
> > information leaked (but nothing that couldn't be obtained by sending
> > queries for individual qtypes anyway), and 2) modestly larger response
> > size (but still a lot better than unminimized ANY responses).
> >
> > Perhaps both approaches should be described in the draft.
> 
> I think I've run out of reasons why the HINFO approach is better than 
> your pick-one idea, which mainly leaves us with the HINFO approach 
> feeling a lot like a dirty hack that makes me want to shower, while 
> yours gets the job done without needing updates to 1035, assuming we 
> feel comfortable with the assertion that ANY doesn't have to mean ALL in 
> the context of an authority server. I like it quite a lot. Sorry again 
> to have missed it when you first brought it up.
> 
> Olafur had a particular code-base in mind as motivation for documenting 
> this, and he may have some perspectives that I have missed. On that 
> note, I will take a few steps away from the microphone.

In the case where people just want to reduce the damage of ANY queries
in reflection attacks, I quite like the PowerDNS option of forcing ANY
queries to TCP via truncation. I'm not sure if this has been documented
in any RFC, but if not then perhaps it bears mentioning too?

Cheers,

--
Shane