Re: [DNSOP] unsolicited HTTPSSVC responses

Ray Bellis <ray@bellis.me.uk> Wed, 27 May 2020 21:48 UTC

Return-Path: <ray@bellis.me.uk>
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 0781E3A0CA3 for <dnsop@ietfa.amsl.com>; Wed, 27 May 2020 14:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=portfast.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 gzfD3Oturo_E for <dnsop@ietfa.amsl.com>; Wed, 27 May 2020 14:48:38 -0700 (PDT)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 AA3433A0CA0 for <dnsop@ietf.org>; Wed, 27 May 2020 14:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3nTG5Q8+CEFRlog+FWT5/hvrxSWQKradB+RIh5wIOUM=; b=QYl9GcR/NLpiZ+Uyyi/2x2AHOt fKk1stka0TPa812wks1ghu4AbQR+OcXxpjpmDjpqx70DoZchBKm0yXvhUsIMnHNV7+Qoe0WjZFTDA d0a9bL9+kXc9sh/nDewfcyNHZYAaT91EI5ymWCCLSGlsj+ub+rp4esL/r7CWiQPWJ6+k=;
Received: from [88.212.170.130] (port=50555 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1je3ue-0004e9-2u (Exim 4.89) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Wed, 27 May 2020 22:48:36 +0100
To: dnsop@ietf.org
References: <CAMOjQcHAKC6ge2te8eqPz3JFmmLrpBoTSt2yKKxFXHpQEyjLqg@mail.gmail.com> <1852098.ajqZCkXiOD@linux-9daj> <e0567177-b1b4-e9e7-d2a8-faddbbc911bc@nic.cz> <CAMOjQcFpq_XF9e5u=ALCNGBa2ZTG0hiJz7QB7JxRNW=+HOgNpw@mail.gmail.com>
From: Ray Bellis <ray@bellis.me.uk>
Autocrypt: addr=ray@bellis.me.uk; keydata= mQENBFvQpEEBCADBbsjhl44JARZXZoAZXoAxsd/227/ItxFHmo+cogL0qhIvn1F++OozY3mR S6ut5iuI1XMGCz2/ewqfp43k2f+o9DxjIBEqKA+M1hg8ivBMWD8//yo8S80DT2Y6GmLnRz64 sRpw0Z3LcmKULKKDU3lD9Uo05s8c2xUzJTxwxFfpjqA108nEemGnu549qV38Jz1OeuD+7P4R 3du97DyaaW5gyj/ggtiQxQtkbHG9aFRn0ASGON0uu49vRxaeuKwaGExb6FWYXJJSQLScfJ3i 356RdwaO/KezCGAhRiJ06AbPTxq2j9cvnShVb1IsxXQn73JgHVsPKDjdYo98ePWYuHWPABEB AAG0HVJheSBCZWxsaXMgPHJheUBiZWxsaXMubWUudWs+iQFUBBMBCAA+AhsDBQsJCAcCBhUK CQgLAgQWAgMBAh4BAheAFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0P8ACgkQ lD9Tw3qX+kJ+MwgAoW1eeAyyDqykaFO+N9XWMcQeFQamm1hWhjNRCOFuygycbwAe0oJPYn+i VsDoooJ/5zoHPdRV6boG8jEq8JcFwNHd5AXBPpAY9VA44ro83K7BSLMQRSfXB/OXCf5uSpb7 6DZQzem3wFys5g4bYqdSzFRiN42SjhSNxyi8KGrcEpqHgrnOBLUh+aPUgcTeFd3Dwxa21Hb/ qpOZvlKwQ7XjnAA6sMqPOmVJF4bg9D5Jg1jUOexPmwtZ1HN1wbpPZWqy3nGPXaHxHCVBp08M 7ZAIKf4QTVXcHbNxLwZtFO0TU7SK35xhzx4oy3faQIVh8K+CUMPQGU8TA3o78SefoPI8DrkB DQRb0KRXAQgAvveTWC0LkjJ2qTJcYqu0ksRKY44UCHyBNy+SfylH7cGd3FTG5qgPnOAhRAfP p7q+rxAep2adQCY4odd0CWQpmg3KhBf1qARW4HqUKMjff8+Gv7YZTiolsH+P8qQamCNemhSa 8+/vsY0roS25ZWHaHDVSIyyvHU6MsDVX8Z1nc1PwNUEqZST3I5ERVUWY/SQOTJp3fVeaU1Mo X3Bmk+7ugmUfb8Ztr63Fv3OrdEVk4ivHD8KP5c49UD9yTsVksfHqV2LN6/zdTU0CvW4SIEtX f7xQNG/o2/J50yW4e7g59ElYQZJxCjJwKusIV61aAmCe3OLLN05Kp23RrX4AwY26ewARAQAB iQE8BBgBCAAmAhsMFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0OkACgkQlD9T w3qX+kKHIggAncjGFT/LRZncAnX1IBwJfqzOzYWLOG4QHPMoHkaxrb+q3GAHXd6RAWgc8UIR fLJDowI1f2oMXh/PvqZkiVdy0qNPwhNP+i7r8OE8Co3Q1VA9Cw3Ysj2UGF5TQ2cF36XjuH9H uMp8Qy0k3lmHZgf7E/hu8u+O3AoBFG5FQ61fJjKTBazRqZmyxcbVyHHAVoAbOYJU+Mb3vfmy UlDa0FHxLHI6+pYEe7IQxzv22lGzdSgr7oVJnAz2V9sodeB2ALs+Jjh2kR0+SVPg+ED+zXWe p5alounzwhu2brS/vAJwXQXSb1R/65L4HliZk4poaC7UxC+6j0Fu7ICZa2IR9JpNnA==
Message-ID: <970122dd-626b-fd99-cfb6-07c44d556664@bellis.me.uk>
Date: Wed, 27 May 2020 22:48:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <CAMOjQcFpq_XF9e5u=ALCNGBa2ZTG0hiJz7QB7JxRNW=+HOgNpw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HGrtoDo-TzpLJBqxXmM-MEcWTbM>
Subject: Re: [DNSOP] unsolicited HTTPSSVC responses
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: Wed, 27 May 2020 21:48:41 -0000


On 27/05/2020 17:40, Eric Orth wrote:

> Maybe a better solution, but considering that the issue I'm dealing with
> is when the stub is unwilling to send additional queries or queries for
> new types out of concerns of middlebox ossificiation (especially from
> older home routers) on additional queries or unknown query types, does
> anybody have any data to show that the multiple qtype EDNS option won't
> cause similar issues?
> 
> But in other cases without as much ossifciation concern, especially when
> using DoH, I'm supportive of any effort to allow querying multiple types
> in the same request.  Would significantly help with some of the security
> concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by
> identifying and blocking the packets just for the HTTPSSVC records.  If
> A/AAAA/HTTPSSVC are all in the same request/response, you can't block
> any of it without blocking all of it.  My one concern of that specific
> proposal is that if the client doesn't know that the server will respond
> for the additional queries, it still has to make separate queries for
> all three, leading to lots of redundant responses when the additional
> types are handled.

In traditional DNS, stub resolvers only talk to a limited set of
upstream resolvers, and they could learn (and cache) information about
their behaviours, in the same way that recursive servers do for
authoritative servers.

You only need to launch one "multi QTYPE" query at a server to learn
whether subsequent queries to that server can take advantage of that
feature.

Ray