Re: [Resolverless-dns] Paper on Resolver-less DNS

Erik Sy <sy@informatik.uni-hamburg.de> Fri, 16 August 2019 20:50 UTC

Return-Path: <sy@informatik.uni-hamburg.de>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E81200C4 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CdYr2l70GcBT for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:50:10 -0700 (PDT)
Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 06B76120018 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 13:50:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 5FB1C120 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 22:50:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de
Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mayCKxUCYQ5m for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 22:50:07 +0200 (CEST)
Received: from users-MBP.fritz.box (i59F57082.versanet.de [89.245.112.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Erik Sy", Issuer "DFN-Verein Global Issuing CA" (verified OK)) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 4B59411F for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 22:50:06 +0200 (CEST)
From: Erik Sy <sy@informatik.uni-hamburg.de>
To: resolverless-dns@ietf.org
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <7458927.46QQVHFPpo@linux-9daj> <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de> <5555002.tMPyTYP4cW@linux-9daj>
Reply-To: sy@informatik.uni-hamburg.de
Openpgp: preference=signencrypt
Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQINBFzVyS4BEADnUWBPWNK8CNxDj8QarMioEQsyEiLkpsln4zxw1cxhTnK+ZHd4wTOh1BZf GVmGZ7wdb/NLiQbENv44okX4mYgJjt32gbVg8ssfScfTEO9PVBgLi5SDtLAxLk8TjF7ETIkG NUWgAQm6Pw6EowjLjMJ4y3fahPcypqtfuO1cxF86pPYAsSG+9iuInpBQoZwuvZu3SLUMXB9l +Xwiy77wEpvPg49pNQhbFqlIZXAHTLyEIlrxG41xXbTt7P5kH333c1cRD//EeC2oEjZhgCBh B4ObFpgL4JxSo71MZFdSDOWfiwMq3kXOwJnPNq9xzcWEItVyLK30fXWt5uZ3YfUcZGpGXv1Y Kl4monIru9NFVSW35FlhHtpgUKdQBKJMeuc1ckZr00zRtd1tf/69rdnjJngR+5RJZE3ykDx4 bJ4P75nqeDUe8adc4S0GeExEgsjVl8QZpCgIrjicA4MQERJKaA3bmCWy5YfCqsZYfbFXrcmq sZopkMTI2X5ZsA3y+jjWlmfDo3Tdu9ddfF8BSB0nTbaPLnJCs878T8HE+Lx9y6QyHlfZ0BJx IuepITZInhbH2c/X5Ipw37+YjNCwzlCOozJDZ/tTj8suMpAKdt4qq3OR1PKyhlilUBiQcYDu 4HfGffihD91Bwxz89YsAtej6EvWLjSfF4fUucFMh9N4GSVQK/QARAQABtCZFcmlrIFN5IDxz eUBpbmZvcm1hdGlrLnVpbi1oYW1idXJnLmRlPokCVgQTAQoAQQIbAwUJB4YfgAULCQgHAwUV CgkICwUWAgMBAAIeAQIXgBYhBADP3q0kgaL0XCmyn7pmQSEb9ifsBQJc1dhqAhkBAAoJELpm QSEb9ifs580P9AiLD49H+bZhNwXZYAXD236D6mKBimXo7EnM8D+v6TXiBKweH35XkKjkHtfU nosHYybfQoV8Rjcdg4lZ8+E/N/7Jk0dcQ6N6gUY1YvMw+t5AiEXMZdz6tQEjwrU+FVlBMN7j WKDpumE4PjkKlxh4IPc9HCgmI0G3uq859nIBvHEpPyCc6z1++9zq+oqP8vUtFLqmuAhQJoOc JSyKv7FYnGhGRnGJGPwkdqwGfS6fZaavhKDXgBcvULXKF7gThZp6kAHG7QhEeNmwL4l/UTOA oAu1pwTfelMwkRWwXyZjgnSqY59ejD6lcFdxZ51O4qIfPmxViaORhNcguD9SvdGw6kdEGNIA az+bd8UfVltz2EkWb+KPbDi6bpa12Zr2Sz+8AakDRhEQ6gSLHicK1cyimhsf66i4SjlUMefX Gq2ImH2xJTMSZi2GN/0JtK/KaBfwArvxoNlWfp3aP97fmXeqNWZVJo2T0+Vvr3hKs00XhU/S 82sbVeFmAJMho5SL4GO+CYEYBQUuIUj131JBfgw3o/YB/WuTD+ELuM+VKP0loXPcgfE4UlEM Ik8yJmzKbRRXfwhCpvoc5T0GFtmQ9szMO9cnll+BiDK3qHNtfMsY09PgjCHnOzwhvYMf7H+3 g0dH3HyIY5Id1YPS88GANpqiG+K1d3vwr2dTER5ZUBuu+pq5Ag0EXNXJLgEQAKRNM1sPfiLC nEVME84YDsek0M+5svW6T1ggJL4dAgUdwYyujSrDdEujBr1AJaVHuJzMKLvqAIQqSvid0qVM zH32rx70LIkaLJE6iGbf/ckHHA1bpgzDRY9dcLj/J/B0F94BFx1oSavnP6uD1qRODnc4c9rZ s/GfmdnTxaC84MG26SWua2ckk81+ZP2qenXnebz1Krv0oRvObGW3QzAAjyg7Fdlb9UqRApmI FbM8xtTtNyls+ISruC8KbYTxv5wPegm817iLox9WpXkkJNbM6I/Nn887yvxsZghbiuoJaqJl OQqkm1wlMroQEIVIfZbe9+iSB7wc9KisxAOxsoFTfOeIwNfgH6HMvzNo+yffLnvjNO3v/Yzx utfP4FL00lVl53aTWj+Hq6Bym1EX+ZSSb+LhDW5MzXig4PYJKgZf2L+fr2SfDoiZMY6Nbirt DMAS2TpKaV4Jgc8576qkhwhG7o9GKPmNWV55lo+sFsGIXCsVB5zWjCq/FUJLg+dE+FR6aIR7 q2npur4rz9os69POEbTcIKn3vfbQ8ytaTuRfFGeTq2VjHXzi/qH49+i5sWLgvZug31f0dDhs PKDFdSTKrv2DFaKW9OsAbPoqqT3krqE0ho8iMbOaPqpEUn8z+cR7Ozuz3BE/ZedetOh/W8Kx K04rYuWGo4bZmf42QoKfWM6vABEBAAGJAjwEGAEKACYWIQQAz96tJIGi9Fwpsp+6ZkEhG/Yn 7AUCXNXJLgIbDAUJB4YfgAAKCRC6ZkEhG/Yn7HwtD/98u7M3mR5ktzk2aCkS7grO7PMbEFqS 0ycCOV+3P3u6gMy0conDgywA+niXVmzO4UsD2u7ncE8Y27Gc+nx0Q0MgmZ7Nju/rlLc/xisU Q++0MLhvwWQU6NRIO9hhaPK8gQzkvTtxRWxKljh7fDqlb9L02rCJ5jZ7zpRxGrRanQxkB7Z6 StY2AAaI6SMH6RDV45J2uVT+Fg5qenA3wqgxeY/V2avEFNHMwbs1v3pUmnPo5KTLvaMbMDaf PKu8akQezpO4CK3ugxV3tMQ43RFT4kdl1XQyaKEffLQUyoUyFHGJfq66+01t4cMu4/CEC7D+ S7pkOn7ANuwgilfINHVZ95Z1HOdadMYvt1Q37qmOaK34K6kHLbTglBIb2eBEp/OcUlOcrFEu 7yq1TU6QSvGA9QZVeAfttyA9YqEawB3j11uJm3xMknqS3SzTE0JxZNyz1Qri6OLnP3uVaXJj BCiiGZf6sgnCa7/JlYrrEIF3ukWQutUfG+1XVq85/gPYnmTlenp4PCIuQVJT+ldG3hPNS1un qX0iEGiV8XdwXy9Gg49QAhNOFn6llW17VP279NvEVa6eRAm5w4mp4L3FgpbFlKkCHZXzMx/7 wuYPd9pj+olW2uDid279lKsUGt0I7MVyad311Fd1WnQQrAuEw6ZduDNZMxnhRV4x0PxwnGEY Ye+WbA==
Message-ID: <16db6a04-5c24-b35c-da0f-666e10a2136b@informatik.uni-hamburg.de>
Date: Fri, 16 Aug 2019 22:50:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5555002.tMPyTYP4cW@linux-9daj>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030905070307090103050701"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/cIYIDFKKU0jHzKsZ5JnMNM8uXpA>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 20:50:12 -0000

On 8/16/19 22:30, Paul Vixie wrote:
> On Friday, 16 August 2019 20:25:39 UTC Erik Sy wrote:
>> ...
>>> does this mean an fbcdn.net link occuring inside a facebook.com object
>>> would require a real DNS lookup, and that any fbcdn.net DNS data
>>> included
>>> in the facebook.com link would be ignored by a correctly implemented
>>> browser?
>>>
>> Let's assume, the user visits the website facebook.com. This website
>> requires the resource https://fbcdn.net/file1. Furthermore, the
>> connection with facebook.com pushes a DNS record for fbcdn.net to the
>> client. Now, the client can use the provided DNS record to retrieve
>> https://fbcdn.net/file1. However, if the server authentication with
>> fbcdn.net fails, this requires the client to evaluate a fallback DNS
>> lookup.
> quite aside from my concerns about the lack of monitoring and control
> by the local network operator (who may have DNS policies which no
> standard ought to ignore or bypass), this seems wrong on the face of it.
Can you please explain your concern and why you think that a limitation
to a same-origin policy is required?
> can you limit it to same-origin policy? web publishers wishing to take
> advantage of whatever benefits "resolverless dns" would offer them,
> can easily rename their linked objects to fit a same-origin policy
> similar to the one used for cookie coverage.
>
>> Expanding this scenario, we can assume file1 requires to retrieve
>> https://a.com/file2 and the connection with fbcdn.net also pushes the
>> corresponding DNS record for a.com. Now, the browser can use the DNS
>> record for a.com to retrieve file2 because these connection occur within
>> the context of the same website assuming a successful server
>> authentication.
>>
>> ...
> thank you for clarifying that; i redouble my earlier (above) ask that
> this NOT be done.
>