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

Erik Sy <sy@informatik.uni-hamburg.de> Fri, 23 August 2019 14:27 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 7F5EA120842 for <resolverless-dns@ietfa.amsl.com>; Fri, 23 Aug 2019 07:27:25 -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 C-nKZ5mFFMFO for <resolverless-dns@ietfa.amsl.com>; Fri, 23 Aug 2019 07:27:21 -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 AFE241200E5 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 07:27:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id F3B8E6E4 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 16:27:17 +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 zEpuYLRNIe4f for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 16:27:17 +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 147F06E3 for <resolverless-dns@ietf.org>; Fri, 23 Aug 2019 16:27:17 +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> <a8d9398b-4fea-0a1e-3fa7-5954d001f9ea@informatik.uni-hamburg.de> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com>
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==
X-Enigmail-Draft-Status: N11101
Reply-To: sy@informatik.uni-hamburg.de
Message-ID: <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de>
Date: Fri, 23 Aug 2019 16:27:16 +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: <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000405060904040606080507"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/gwO8J3urnIVbCr1QUEuza3F0oX4>
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 14:27:26 -0000

On 8/23/19 14:05, Vittorio Bertola wrote:
>> Il 23 agosto 2019 13:50 Erik Sy <sy@informatik.uni-hamburg.de>; ha scritto:
>>
>> Do you think the bullet point "There is a risk of rendering a site
>> unusable." does apply to DANE TLSA?
> Sure, but it also applies to normal HTTPS certificates without pinning. How many times did you try to access an HTTPS website and were stopped by the browser, because the certificate was expired and the owner forgot to renew it, or because the certificate was self-signed, even if the site had not been attacked? It happens every day, but it's not a good reason to stop using certificates and validating them properly - it's rather a good reason for the site owner to get a better webmaster. 
>
Chrome establishes trust in a certificate if it is issued by a valid CA
and included in the Certificate Transparency (CT) logs. Here, the CT
allows to monitor the certificates issued by the CAs. In this ecosystem,
it is unlikely that valid CAs issue illegitimate certificates because
the trust in misbehaving CAs can be revoked at any time.

Additional pinning of certificates provides the benefit that an
illegitimate certificate can be detected during the server
authentication. Note, that CT can detect this only in the aftermath. As
a drawback of pinning, a misconfiguration of this mechanism always leads
to a fatal error. The trade-off at hand is catching misbehaving CAs
before the connection establishment and accepting hard failures due to
possible misconfiguration versus catching the malicious CA only in the
aftermath of the connection establishment. I think that Chrome decided
for the latter one.

Erik