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

Erik Sy <sy@informatik.uni-hamburg.de> Fri, 23 August 2019 11: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 182DB12081A for <resolverless-dns@ietfa.amsl.com>; Fri, 23 Aug 2019 04:50:54 -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 AeF0_0-WbzUL for <resolverless-dns@ietfa.amsl.com>; Fri, 23 Aug 2019 04:50:51 -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 3C80B1200A3 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 04:50:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 56B49973 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 13:50:49 +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 Eh0xydqdIxf3 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 13:50:48 +0200 (CEST)
Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (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 5A7DC972 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 13:50:48 +0200 (CEST)
To: resolverless-dns@ietf.org
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <4568720.uvMTqBdgP4@linux-9daj> <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de> <34813218.VKkrhzyXsx@linux-9daj> <ae355776-a1bb-cf23-f380-133439661d1f@informatik.uni-hamburg.de> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com>
Reply-To: sy@informatik.uni-hamburg.de
From: Erik Sy <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: <a8d9398b-4fea-0a1e-3fa7-5954d001f9ea@informatik.uni-hamburg.de>
Date: Fri, 23 Aug 2019 13:50:47 +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: <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050307060103040409070807"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/bkIM6FDtdYJZKQ6oZB_n3Mn4Uo0>
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, 23 Aug 2019 11:50:54 -0000

On 8/23/19 13:11, Vittorio Bertola wrote:
>> Il 23 agosto 2019 11:37 Erik Sy <sy@informatik.uni-hamburg.de> ha scritto:
>>
>> In my view, DANE TLSA is an approach to do public key pinning. The web
>> already collected a lot of experience with public key pinning as this
>> can be also done using other protocols than DNS. In summary, the Chrome
>> browser deprecated this mechanism last year [1]. Assuming that DANE TLSA
>> would be widely supported on client systems, I think that Chrome would
>> not start using this mechanism to do public key pinning.
>>
>> 1:
>> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ
> According to the message you linked to, the main reason for deprecating HPKP was that it was hard for site operators to make sure that the pinned certificate matched the set of CAs that would be available in browsers at any time in the future, and the chain of intermediate certificates that each CA could use. This is not a problem with DANE, since DANE validates the certificate for the current connection and not for the future (so it's not really pinning it, just validating it every time), and does not depend on CAs and on the browser's acceptance of them. Even "hostile pinning" is much harder with DANE, since it would require the attacker to gain control of both the web server and the authoritative name server, rather than just the web server; and it would cease to have effects immediately once found and remediated.
>
> Actually, moving to DANE validation in the browser would have been quite a reasonable consequence of the analysis in the message.
>
Do you think the bullet point "There is a risk of rendering a site
unusable." does apply to DANE TLSA?