Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 13 September 2018 15:31 UTC

Return-Path: <ietf@kuehlewind.net>
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 A3EE1130DDA for <dnsop@ietfa.amsl.com>; Thu, 13 Sep 2018 08:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 1vutTdyqp2CO for <dnsop@ietfa.amsl.com>; Thu, 13 Sep 2018 08:31:50 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A51130E61 for <dnsop@ietf.org>; Thu, 13 Sep 2018 08:31:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=nPGwaEhusDNdgSXs71/BhzSyAiWem5BVb0JjIkhGlE1aB2MrZUVkllZu7yJtZA1khoYslP65GkKSrG5dfRHddlQ6sYPGgpN41Isj2fn7zWJK04Zla+kOsLvQUy0laeyZ3+KSHrm9ZlppWd+xLm62pjgCtqx5nJJS/ZJH7Sah4FI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 22759 invoked from network); 13 Sep 2018 17:25:06 +0200
Received: from i577bceed.versanet.de (HELO ?192.168.178.24?) (87.123.206.237) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Sep 2018 17:25:06 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CAN6NTqwTt5SZ=_69kAd31qEtFKnZsOu7sShy26uOoShZtyJkkQ@mail.gmail.com>
Date: Thu, 13 Sep 2018 17:25:04 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-refuse-any@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EBC432D-6B59-4560-82B8-9CBA449068CA@kuehlewind.net>
References: <153658244644.26649.463764101726763839.idtracker@ietfa.amsl.com> <CAN6NTqwTt5SZ=_69kAd31qEtFKnZsOu7sShy26uOoShZtyJkkQ@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180913152506.22750.90467@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kjkN935iokDklxOtz5KpwSqv45Y>
Subject: Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
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: Thu, 13 Sep 2018 15:31:54 -0000

Hi Olafur,

please see below.

> Am 13.09.2018 um 00:02 schrieb Ólafur Guðmundsson <olafur@cloudflare.com>:
> 
> 
> 
> On Mon, Sep 10, 2018 at 11:27 PM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I'm wondering if it would make sense to provide stronger guidance that the
> conventional ANY response SHOULD be provided if TCP is used as TCP already
> provides a retrun routability proof...? Also maybe provide a refernce to
> RFC7766?
> 
> This has nothing to do with "retrun routability"  if big answers are given to resolver via TCP then the resolver can be used as amplifier and there Millions of those on the net. 

With TCP you usually set up a TCP connection (3-way handshake) then send the request on that connection and get the reply on that connection. You can not change the IP address in the mean time. So there should not be that amplification attack anymore. That was what I was saying.

> 
> IMHO the only time big ANY answer CAN be returned is when the connection is authenticated and approved. 

Not sure what you mean by „approved" but I guess that is what TCP gives you. If you really need authentication you’d need to use TLS but not sure why that would help.
> 
> 
> And one smallish comment: Would it make sense to refer
> draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC)
> instead of RFC7719?
> 
> 
> Hope this happens by RFC-editor or in AUth48

It will only happen if you replace [RFC7719] which [draft-ietf-dnsop-terminology-bis-09] because then the RFC editor knows that there is a dependency and will wait with the publication until draft-ietf-dnsop-terminology-bis-09 has an RFC number and then replace automatically [draft-ietf-dnsop-terminology-bis-09] with the RFC-to-be.

Mirja



> 
> Olafur
>  
> 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com blog.cloudflare.com