From nobody Tue Aug 13 05:07:52 2019 Return-Path: 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 E6809120130 for ; Tue, 13 Aug 2019 05:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 ARiQSUSsQ0G0 for ; Tue, 13 Aug 2019 05:07:46 -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 6685B120125 for ; Tue, 13 Aug 2019 05:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 4E2AA26A for ; Tue, 13 Aug 2019 14:07:39 +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 6HbnYfAR24-r for ; Tue, 13 Aug 2019 14:07:38 +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 840A7269 for ; Tue, 13 Aug 2019 14:07:36 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: resolverless-dns@ietf.org From: Erik Sy 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: Date: Tue, 13 Aug 2019 14:07:35 +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 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060805040106020500050000" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 12:07:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060805040106020500050000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi all, I wrote a paper to clarify the design of resolver-less DNS and to investigate its feasibility. You can find the paper here: https://svs.informatik.uni-hamburg.de/publications/2019/2019-08-13-Sy-pre= print-Enhanced_Performance_and_Privacy_via_Resolver-Less_DNS.pdf In total, I think this is a great performance-optimization especially for clients on high-latency access networks. Furthermore, it can improve the client's privacy posture towards the recursive DNS resolver. Best regards, Erik --------------ms060805040106020500050000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTMxMjA3MzVaMC8GCSqGSIb3DQEJBDEiBCBDsncfOu7s ks8dIb3+9p7jKpCgI9DhQ/ldvCssdBiesDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBMFB+ippqpzUt5seZBdWMk8y1v2hSsIbEaDPy6 RThLVw7lLT+jkHGX3oHAiifCnjhmx91zl+YQZ11yBGSgQns2i1EWthTdqg4wEXgECl12aqwd eQhO95grDFdv0poYRNSev/ZeYqWN4Rh19smUIiCDrT/qVCFGTE6jNmFkptAG3ZnczhEtKmha Cj0SWaLJ6R3agKTtUdQf2dYSgjjYCCZqr6YAgmc9/YM63/BI09K9MaYBvQNM6SDq87xQUatx XZ8nCWbeM6e2LBC2PxSky39XuymBuZucrr6pAHAmezOD6UXziHNMGvoYviwayZDzZKyP9Lun O8+kAp526DudxSYOAAAAAAAA --------------ms060805040106020500050000-- From nobody Wed Aug 14 14:11:44 2019 Return-Path: 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 544BB120FA2 for ; Wed, 14 Aug 2019 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 jH3rEMAoEyjd for ; Wed, 14 Aug 2019 14:11:37 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1287B120F64 for ; Wed, 14 Aug 2019 14:11:36 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id f17so1395386otq.4 for ; Wed, 14 Aug 2019 14:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+PfrGei01iwIXGK2k8HLW84IN+Mv40ZwXt739pA+t5k=; b=XDixzwsWyoE9C4Wi36iba/fSOIvGaPNOMeivjgc8zEK9vCh9mpKtXGZaJV1Z/9DTbc c2E6GyXkSsUTdTIfV6NgYoio2idLQS6LtsGzSUus8jR2//y73V9/ySnBMJsmm4ih5XWh 0Y7p3ENHJSvSM8/7hOP/j4/EAfnQLs1rotPri6a13mHiZ9xm3vXPX342Hd73dLfte6c0 Es2V3cGJ1DclaFTqg6pQnN8zjdn1YevsyTko/ZVDWkj8jiy7xLej9U53VIP3yMTN8CKM b8AdCEeF2LOm2iERkvBVkf8C1unjuJ4HUhu8p95esDmMAeaZtJlTgV5sCSptlwCjKOEm iFcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+PfrGei01iwIXGK2k8HLW84IN+Mv40ZwXt739pA+t5k=; b=qb3UP9es7KXWi42ogUgloXqgEMPJW9I2RTHNSw+FRZmYImfPhnMJRKhYL/QTWiZTDP Lv4U5Ji5k5F/Ae+93ABrh0EplhHDNaVeimUHWXNNqgs2O6gS7+e9PR2nnTT/BVIO+fjy YBzK8jaOjz4b+6yKQwZX6aJIoX4NlcHXulogGdzQr2TpGISvYEnnguztSo8NWZFsk/oH kD5DIS38HILvc9B+wt5L03h2iyQ5yoAAl04CIVrZR8eeo54gsKLSyiADbaF8kiPwr45V eggwolcdRvrrWyq+QLl3Z6lqjrp21UfJbtjXP2dD+WxrbHgt5zDGXXTZM0RicWoB05Ig EYxw== X-Gm-Message-State: APjAAAUb6e8aCQBVg9SGTyVSnC+O2Zjg3qKX7JdAD8HwH+lNYhzPoLKH rIURbD2uZ1sJBd08g33CPhXvgYlqTr14YOwbQUW8+2EcLFg= X-Google-Smtp-Source: APXvYqxqM/zFPrmVWVbHXoYVRXDOrepGXf355tVT9Asne///zz2lDelCncwNpf1TTxlg9TBhG3Zv/OWBSkCczv+e9pw= X-Received: by 2002:a5d:8759:: with SMTP id k25mr1901858iol.307.1565817094938; Wed, 14 Aug 2019 14:11:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 14 Aug 2019 17:11:22 -0400 Message-ID: To: sy@informatik.uni-hamburg.de Cc: resolverless-dns@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c3a71d05901a3311" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 21:11:43 -0000 --000000000000c3a71d05901a3311 Content-Type: multipart/alternative; boundary="000000000000baa1ba05901a3342" --000000000000baa1ba05901a3342 Content-Type: text/plain; charset="UTF-8" Thanks for conducting this investigation, Erik! In my view, the two main concerns with resolverless architectures have been (1) simplifying stolen key attacks and (2) potential interference with DNS-based load balancing. Currently, an attacker who has stolen a TLS private key also needs control of the victim's network in order to mount an impersonation attack. Resolverless DNS (especially without DNSSEC, as in your model) might make these attacks much easier to execute, by sending the victim a DNS record that points the compromised domain to the attacker's IP address. Domains that rely on DNS-based load balancing have concerns about third parties handing out DNS records for their domains. These third parties might (accidentally) provide the same DNS record to all of their users, overloading a particular server instead of spreading the load across many servers. If you're interested in this topic, I hope you'll think a bit about these problems, and see if you find a way to solve them. On Tue, Aug 13, 2019 at 8:07 AM Erik Sy wrote: > Hi all, > > I wrote a paper to clarify the design of resolver-less DNS and to > investigate its feasibility. > You can find the paper here: > > https://svs.informatik.uni-hamburg.de/publications/2019/2019-08-13-Sy-preprint-Enhanced_Performance_and_Privacy_via_Resolver-Less_DNS.pdf > > In total, I think this is a great performance-optimization especially > for clients on high-latency access networks. Furthermore, it can improve > the client's privacy posture towards the recursive DNS resolver. > > Best regards, > Erik > > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --000000000000baa1ba05901a3342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for conducting this investigation, Erik!

In my view, the two main concerns with resolverless architectures = have been (1) simplifying stolen key attacks and (2) potential interference= with DNS-based load balancing.

Currently, an atta= cker who has stolen a TLS private key also needs control of the victim'= s network in order to mount an impersonation attack.=C2=A0 Resolverless DNS= (especially without DNSSEC, as in your model) might make these attacks muc= h easier to execute, by sending the victim a DNS record that points the com= promised domain to the attacker's IP address.

= Domains that rely on DNS-based load balancing have concerns about third par= ties handing out DNS records for their domains.=C2=A0 These third parties m= ight (accidentally) provide the same DNS record to all of their users, over= loading a particular server instead of spreading the load across many serve= rs.

If you're interested in this topic, I hope= you'll think a bit about these problems, and see if you find a way to = solve them.

On Tue, Aug 13, 2019 at 8:07 AM Erik Sy <sy@informatik.uni-hamburg.de> wrot= e:
Hi all,

I wrote a paper to clarify the design of resolver-less DNS and to
investigate its feasibility.
You can find the paper here:
https://svs.informatik.uni-hamburg.de/= publications/2019/2019-08-13-Sy-preprint-Enhanced_Performance_and_Privacy_v= ia_Resolver-Less_DNS.pdf

In total, I think this is a great performance-optimization especially
for clients on high-latency access networks. Furthermore, it can improve the client's privacy posture towards the recursive DNS resolver.

Best regards,
Erik


--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--000000000000baa1ba05901a3342-- --000000000000c3a71d05901a3311 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBnmXmCtecHA/6SSYE0g8to tvMvflzzi+rnqY+MnwwwPzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA4MTQyMTExMzVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcRWd6TkZEqPiYaIJIDsBD7H3i3EeX1ajwsN+q4fU ngyEPm2qbd0/1PFg//0w/M6MlagUdUWgEAjuHVw2u9qq/hNOocgweJDk2WovJxf31r91bupfE452 +cVx997UeBenehVo33q3epvHWes9g7MSkLSG7h+8PWofCu4jfwxBGDSBKmzpnyB11Mazb+YfzEHq YYv/6yQxn6x3NtQjK2YC4xZ7lrph2V1mlhzeamEozK/jJ5RIH5xRwnFQQNeOrb61Xkxq7aoiZi0R f3q/kcMlk7A2qdj2Ojl6Ai5RJgLO5ugSyW3yw98xFTW12onzPDuZMFPlWMV8uD2KIrj5ho71FQ== --000000000000c3a71d05901a3311-- From nobody Thu Aug 15 03:43:28 2019 Return-Path: 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 A8BE712008B for ; Thu, 15 Aug 2019 03:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 Fiqiw1iRasLq for ; Thu, 15 Aug 2019 03:43:24 -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 91E44120072 for ; Thu, 15 Aug 2019 03:43:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E9F42A6E; Thu, 15 Aug 2019 12:43:20 +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 C6g+5fPURp9x; Thu, 15 Aug 2019 12:43:20 +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 071E9A6D; Thu, 15 Aug 2019 12:43:19 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Ben Schwartz Cc: resolverless-dns@ietf.org References: From: Erik Sy 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: Date: Thu, 15 Aug 2019 12:43:19 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040604070207010700040109" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 10:43:27 -0000 This is a cryptographically signed message in MIME format. --------------ms040604070207010700040109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Thank you for your feedback, Ben! On 8/14/19 23:11, Ben Schwartz wrote: > Thanks for conducting this investigation, Erik! > > In my view, the two main concerns with resolverless architectures have > been (1) simplifying stolen key attacks and (2) potential interference > with DNS-based load balancing. > > Currently, an attacker who has stolen a TLS private key also needs > control of the victim's network in order to mount an impersonation > attack.=C2=A0 Resolverless DNS (especially without DNSSEC, as in your > model) might make these attacks much easier to execute, by sending the > victim a DNS record that points the compromised domain to the > attacker's IP address. > The described attack of a compromised TLS private key or even a broken PKI is quite strong. Certainly, it is not a design goal of DNS to mitigate these attacks. However, let's assume that this attack is relevant. In the traditional DNS as well as in the server-less DNS network paths involving the HTTPS server (victim) and the corresponding authoritative nameserver are vulnerable to such an impersonation attack as shown in this figure (https://erik-sy.de/Resolver-less_DNS_Attack.pdf). Resolver-less DNS replaces only the vulnerable paths involving the resolver with the paths involving the HTTP server providing the DNS records. In my view, none of these DNS designs protects against the described impersonation attacks and the attack surface remains substantially the same across these design= s. > Domains that rely on DNS-based load balancing have concerns about > third parties handing out DNS records for their domains.=C2=A0 These th= ird > parties might (accidentally) provide the same DNS record to all of > their users, overloading a particular server instead of spreading the > load across many servers. I think, that this is not a new problem introduced by the resolver-less DNS design. Moreover, it describes a general drawback of DNS-based load balancing that one is dependent on 'unreliable' third parties to spread the load. For example, it is known that some resolvers ignore small TTLs of their cached DNS records impacting this load balancing mechanism. Is anybody interested in co-authoring an ID on resolver-less DNS? Best regards, Erik=C2=A0 > If you're interested in this topic, I hope you'll think a bit about > these problems, and see if you find a way to solve them. > > On Tue, Aug 13, 2019 at 8:07 AM Erik Sy > wrote: > > Hi all, > > I wrote a paper to clarify the design of resolver-less DNS and to > investigate its feasibility. > You can find the paper here: > https://svs.informatik.uni-hamburg.de/publications/2019/2019-08-13-= Sy-preprint-Enhanced_Performance_and_Privacy_via_Resolver-Less_DNS.pdf > > In total, I think this is a great performance-optimization especial= ly > for clients on high-latency access networks. Furthermore, it can > improve > the client's privacy posture towards the recursive DNS resolver. > > Best regards, > Erik > > > --=20 > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --------------ms040604070207010700040109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTUxMDQzMTlaMC8GCSqGSIb3DQEJBDEiBCDDIzsAd33s GbLnZvgmdf/3YAUx4LCEZbdJbtQ70rr3+DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBp+/nre3WU05TapDwIMtmr9dVnpfQ7RVUvZzyb 4xxu+dDE0YrM5VJjo98SnoWoc8I0LlU48Ic+qep0PwuElrceHYQ+FDSbzJEkSmLnNXsv4vJp aiO2uDNslzCZ9RGC7G4pAG1FwsZuODtPcZ+y8caJOyMbw9mCrJCg8noWOEHG6Aen5rYaSnTM Cyv3I2xMEBpQXZ7eoCP6zRe4vGwVXm7MO8fIo1qQQpMasavnjdazITy4ZlahJf0mvDnaxtzn +XXSWIHtWsxeXKKXb8uAPifbwR+PFjR8BYDlVEI6PRUzjQ+5u3DgxBUVJD8mqUATDmFGhIIf 2NUORh90cfdhDlceAAAAAAAA --------------ms040604070207010700040109-- From nobody Thu Aug 15 09:39:46 2019 Return-Path: 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 0EA641200D7 for ; Thu, 15 Aug 2019 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jHnVmPUJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=CSbn7Ap3 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 YnQdguv5Vd81 for ; Thu, 15 Aug 2019 09:39:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 63304120108 for ; Thu, 15 Aug 2019 09:39:41 -0700 (PDT) Received: (qmail 10509 invoked from network); 15 Aug 2019 16:39:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=290b.5d558acb.k1908; i=printer-iecc.com@submit.iecc.com; bh=oZ0xY/k3ex3yPn9MfFUgMEcMxgg3AKExzfkEmpQXcm8=; b=jHnVmPUJnbuN4P62g6ba5uuMxknIndir4A5ou1m3hNqq0+vDCZylqWNqp2F5LhZ6fXgQSeIx6fji9eKLmhzS/u6T10whdbGZEObcWW2oL9oEb/3kOdEGd36zWE/Buy04JfvvS+ti6zbaLfCVaGPOicFpR5rJD3FECF32v+Cj/m0P5wgFq0l+uyKOiicHTHAiY/AqqkiVfF4da2wqkH58OucvXxOWZbTaett8uWBjtau3OnJAxB3gLpp8EqVQaWFj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=290b.5d558acb.k1908; olt=printer-iecc.com@submit.iecc.com; bh=oZ0xY/k3ex3yPn9MfFUgMEcMxgg3AKExzfkEmpQXcm8=; b=CSbn7Ap3jV3G/PouZ4V22HDdgGiBMczDakHHhFGkBaDTPCgFWFK4+NyN3hB5FZBsvQdSv4feacqbjKTuP1Mt1iwAX0t0V6zLSRT6PkSR6NmTrsWFK7H+/g+lGHM2scNj46TWy2/fnhCNggJd8J4c4FR7/b/a3FFblSo14uEpenPiTkZ4747CnYxoTkpKizh/btCL1WSY6cxKzQysC5hyQWiadslGdhGjIk/6QqZimZ47ep1TCDgbEUnjt3/H9kN8 Received: from ary.local ([73.33.141.87]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 15 Aug 2019 16:39:39 -0000 Received: by ary.local (Postfix, from userid 501) id CF9CB85D108; Thu, 15 Aug 2019 12:39:38 -0400 (EDT) Date: 15 Aug 2019 12:39:38 -0400 Message-Id: <20190815163938.CF9CB85D108@ary.local> From: "John Levine" To: resolverless-dns@ietf.org Cc: bemasc@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 16:39:44 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Thanks for conducting this investigation, Erik! > >In my view, the two main concerns with resolverless architectures have been >(1) simplifying stolen key attacks and (2) potential interference with >DNS-based load balancing. I also like the paper but it misses the largest concern with resolverless DNS: it circumvents DNS based access controls. I realize this is not a popular position in the IETF, but there are lots of perfectly good reasons that networks provide filtered DNS. Even though it has usually been technically easy to circumvent, most people don't and it's been good enough. If it's widely circumvented, we can expect much more intrusive filtering with a lot more collateral damage. R's, John From nobody Thu Aug 15 09:54:11 2019 Return-Path: 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 019E71200D5 for ; Thu, 15 Aug 2019 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 nmoKP5nOdcUJ for ; Thu, 15 Aug 2019 09:54:06 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F85120074 for ; Thu, 15 Aug 2019 09:54:06 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id i22so470743ioh.2 for ; Thu, 15 Aug 2019 09:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YMDbbvt1I6bjY1XZhn9ZhNoVD052D77caTGDmg7UUW8=; b=cDSDJ1mN+pkrc+HUfZZUBhDVq/T/iv6z5QEclanr+mhJGbj0r4JERezifMEE/sxE6n 4Q+Y+3qgnrkJ1APzyvb1yriDg3B+v+kSjBi82Ia7IlXKxhAPv95UWIwYtuJD/7feOMiu 9v5JCRfvFofA2Q12P9+z7YFSeD16bYioxarSs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YMDbbvt1I6bjY1XZhn9ZhNoVD052D77caTGDmg7UUW8=; b=d5FjseTfe5aLRB5DIG5AjbMekWMTu6kVwCFNfKf7wNN83b4F9z9hglT1EXZskXG3/E VbtxNmnIQSH0EdfHVP4IXeLOv6bGVdz8dhNs1T/5zKKj78IZMOBsASpos7FlfMv8RMm8 O269GW2givHfPRqR7eZpntYSd1G+lY/i3CVi+wl61OyO+GXOGb+y085gla8WbTlBUhYM WbL59rGXYfRubp6Sr65tX3MXi1xUOjtzEVrPKUC2XCaZsdksBZbcIaJ0lR7gXrjxc30l nbyS+8kl+hWQpn0PSIGIj5HbrV8vvk9KZqlKa88RpRafZHeiOwKIqj9wNAV7TpLIpMLx wg1g== X-Gm-Message-State: APjAAAVmKnfEAB8yA0N9hTUfIsKLhFp6UwEh2ncqmi8EhYi0uEUi3UIW qQ6MyYQjuHQbc/MduKr8ezfx7w== X-Google-Smtp-Source: APXvYqwf8eAp48XHkjDLB7P8dghDUvVi+4wO+oVunuU44cE4FOBDqXEHqEd51oicLqac/tx0QszDqQ== X-Received: by 2002:a02:bb8c:: with SMTP id g12mr3065021jan.116.1565888045110; Thu, 15 Aug 2019 09:54:05 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:e4d3:9643:614c:849e? ([2607:f2c0:e786:128f:e4d3:9643:614c:849e]) by smtp.gmail.com with ESMTPSA id r7sm2490632ioa.71.2019.08.15.09.54.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 09:54:04 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E58B2E4D-67BB-4388-9F31-C96D3FB0E503"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 15 Aug 2019 12:54:01 -0400 In-Reply-To: <20190815163938.CF9CB85D108@ary.local> Cc: resolverless-dns@ietf.org, bemasc@google.com To: John Levine References: <20190815163938.CF9CB85D108@ary.local> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 16:54:10 -0000 --Apple-Mail=_E58B2E4D-67BB-4388-9F31-C96D3FB0E503 Content-Type: multipart/alternative; boundary="Apple-Mail=_B4FBFDEA-672A-4F7A-8D3F-3B5779EFD61C" --Apple-Mail=_B4FBFDEA-672A-4F7A-8D3F-3B5779EFD61C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, On 15 Aug 2019, at 12:39, John Levine wrote: > In article = you = write: >> -=3D-=3D-=3D-=3D-=3D- >> -=3D-=3D-=3D-=3D-=3D- >>=20 >> Thanks for conducting this investigation, Erik! >>=20 >> In my view, the two main concerns with resolverless architectures = have been >> (1) simplifying stolen key attacks and (2) potential interference = with >> DNS-based load balancing. >=20 > I also like the paper but it misses the largest concern with > resolverless DNS: it circumvents DNS based access controls. This is an area where applicability is important, I think. I suggested = splitting the problem space once before into phases (the message I sent = seems not to be in the add list archive, so no link, but copy below). In = that crude taxonomy, DNS-based access control seems applicable to the = initialisation phase but not so much to the established phase. If we can assume for the sake of this topic that there is a security = model that makes sense that constrains what DNS data could be exchanged = between server and client within an HTTPS bundle, and if access control = was already exercised during the initialisation phase, perhaps it's not = needed in the established phase. In that case, in that phase, = resolverless DNS might be a perfectly reasonable and uncontentious = choice. Joe > Begin forwarded message: >=20 > From: Joe Abley > Subject: lifecycle of an engagement between an application and a = service > Date: 9 April 2019 at 10:26:22 EDT > To: add@ietf.org >=20 > Hi all, >=20 > Vittorio and Stephen reminded me of some handwaving I inflicted on = various people in the Hilton bar in Prague. Perhaps now is the time to = widen the circle of injury. >=20 > Consider an end-user who wants to use some service over the Internet. = I'll suggest we can consider the overall engagement between the end-user = and the service in terms of a number of phases, each of which has some = characteristics that are usefully different from others. My intent is to = see whether we can reduce the scope of the problem from "all resolution = in the world, ever" to something smaller. >=20 > For example, in the taxonomy below, I think we are mainly arguing = about mechanisms within the initialisation phase. I speculate about = different name resolution protocols being architecturally viable in the = following established phase. >=20 > -- Initialisation Phase -- >=20 > The end-user uses an application to begin a session with some service = or other. Unless the addresses of the relevant service endpoints in the = network are hard-coded into the application (in which case stern = frowny-face) this will involve some name resolution. >=20 > For popular services today that name resolution often involves = enterprise DNS services who generate responses based on a set of = criteria specified by the service provider, e.g. the (city, provider) = pair that the DNS provider guesses corresponds to the end-user, based on = things like the EDNS(0) client-subnet option, the address of the = resolver, etc. This process involves approximations and assumptions. The = QNAMEs are generally generic (e.g. they are bigservice.org = , not user-specific-random-label.bigservice.org = ). >=20 > The end-user uses a resolver that has been provided as part of the = process of joining the local network, or one that has been = hand-configured by the end-user, or one that is specified by the vendor = of the application. >=20 > The result of the resolution process is a set of one or more initial = service endpoints, layer-3 addresses. The application stands up one or = more transport layer sessions to those initial service endpoints. Those = transport layer sessions often incorporate some end-point authentication = (e.g. a bundle of TLS sessions with some appropriate certificate = validation process). >=20 > The control point whereby someone (e.g. a resolver operator, an = on-path network operator) can prevent the application from communicating = with the service by DNS name exists within this phase. The choice of = name resolution mechanism in this phase is hence contentious. >=20 > The control point whereby an on-path network operator can prevent the = application from communicating with the service by layer-3 address = exists within this phase. This is potentially independent of the choice = of name resolution protocol or transport. >=20 > There is potential for metadata surveillance during this phase -- the = fact that an application located at one address is attempting to = initialise a service using a particular DNS name. This is a potential = privacy concern. There is potentially a similar risk based on layer-3 = address which is independent of name resolution. >=20 > -- Established Phase -- >=20 > The application begins to communicate with the service end-points. >=20 > Additional name resolution may well occur during this phase since = popular services are distributed, network performance and topology is = dynamic and end-users are mobile. The QNAMEs involved might be = user-specific and designed to trigger cache-misses (e.g. incorporating = pseudo-random 64-character labels), e.g. because there is some = user-specific behaviour that is incorporating the resolution process as = a communications channel, or for reasons of traffic-engineering as = described in the enterprise DNS commentary above, or because it's more = reliable than using low TTLs, or something like that. >=20 > By the time an application's engagement with a service enters this = phase, the opportunity to block the engagement has passed. The nature of = the name resolution that exists within this phase is therefore = potentially less contentious than in the initialisation phase. The = communications channels between the application and the service endpoint = have been authenticated at this point, and so to some degree the same = trust that the application puts in those channels for other objects = might also apply to name resolution. >=20 > As a thought experiment, perhaps a particular web service is easier to = manage if all the resolution in the established phase happens inside the = same HTTPS bundle that carries HTML and other objects; performance = measurements executed in javascript in a browser could be shared with = the service provider which could then push user-specific names to = optimise service performance and that process might be architecturally = cleaner and cheaper than using the more circuitous approach necessary = with enterprise DNS services. The control points mentioned in the = initialisation phase are unavailable in this case, but perhaps that's = ok. >=20 > Even without such sophisticated resolution requirements, making the = service provider directly responsible for the name resolution involved = in using their service eliminates some attack vectors, e.g. the chance = that some required resolution in this established phase might be = hijacked by a third party as part of a phishing attack. >=20 > -- Termination Phase -- >=20 > For many web services this seems like it is probably a noop, but it = seems wrong not to include it by way of acknowledging that all good = things must surely end. >=20 >=20 > Joe --Apple-Mail=_B4FBFDEA-672A-4F7A-8D3F-3B5779EFD61C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = John,

On 15 Aug 2019, = at 12:39, John Levine <johnl@taugh.com> wrote:

In article <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.= com> you write:
-=3D-=3D-=3D-=3D-=3D-
-=3D-=3D-=3D-=3D-=3D-

Thanks for conducting this investigation, = Erik!

In my view, the two main concerns = with resolverless architectures have been
(1) simplifying = stolen key attacks and (2) potential interference with
DNS-based load balancing.

I also like the paper but it misses the largest concern = with
resolverless DNS: it circumvents DNS based access = controls.

This is = an area where applicability is important, I think. I suggested splitting = the problem space once before into phases (the message I sent seems not = to be in the add list archive, so no link, but copy below). In that = crude taxonomy, DNS-based access control seems applicable to the = initialisation phase but not so much to the established = phase.

If we can assume for the sake = of this topic that there is a security model that makes sense that = constrains what DNS data could be exchanged between server and client = within an HTTPS bundle, and if access control was already exercised = during the initialisation phase, perhaps it's not needed in the = established phase. In that case, in that phase, resolverless DNS might = be a perfectly reasonable and uncontentious choice.


Joe

Begin = forwarded message:

From: Joe Abley <jabley@hopcount.ca>
Subject: lifecycle of an = engagement between an application and a service
Date: 9 April 2019 at 10:26:22 EDT
To: add@ietf.org

Hi all,

Vittorio and Stephen reminded me of some handwaving I = inflicted on various people in the Hilton bar in Prague. Perhaps now is = the time to widen the circle of injury.

Consider an end-user who wants to use = some service over the Internet. I'll suggest we can consider the overall = engagement between the end-user and the service in terms of a number of = phases, each of which has some characteristics that are usefully = different from others. My intent is to see whether we can reduce the = scope of the problem from "all resolution in the world, ever" to = something smaller.

For example, in the taxonomy below, I think we are mainly = arguing about mechanisms within the initialisation phase. I speculate = about different name resolution protocols being architecturally viable = in the following established phase.

-- Initialisation Phase --

The end-user uses an = application to begin a session with some service or other. Unless the = addresses of the relevant service endpoints in the network are = hard-coded into the application (in which case stern frowny-face) this = will involve some name resolution.

For popular services today that name = resolution often involves enterprise DNS services who generate responses = based on a set of criteria specified by the service provider, e.g. the = (city, provider) pair that the DNS provider guesses corresponds to the = end-user, based on things like the EDNS(0) client-subnet option, the = address of the resolver, etc. This process involves approximations and = assumptions. The QNAMEs are generally generic (e.g. they are bigservice.org, = not user-specific-random-label.bigservice.org).

The end-user uses a = resolver that has been provided as part of the process of joining the = local network, or one that has been hand-configured by the end-user, or = one that is specified by the vendor of the application.

The result of the = resolution process is a set of one or more initial service endpoints, = layer-3 addresses. The application stands up one or more transport layer = sessions to those initial service endpoints. Those transport layer = sessions often incorporate some end-point authentication (e.g. a bundle = of TLS sessions with some appropriate certificate validation = process).

The = control point whereby someone (e.g. a resolver operator, an on-path = network operator) can prevent the application from communicating with = the service by DNS name exists within this phase. The choice of name = resolution mechanism in this phase is hence contentious.

The control point = whereby an on-path network operator can prevent the application from = communicating with the service by layer-3 address exists within this = phase. This is potentially independent of the choice of name resolution = protocol or transport.

There is potential for metadata surveillance during this = phase -- the fact that an application located at one address is = attempting to initialise a service using a particular DNS name. This is = a potential privacy concern. There is potentially a similar risk based = on layer-3 address which is independent of name resolution.

-- Established Phase = --

The = application begins to communicate with the service end-points.

Additional name = resolution may well occur during this phase since popular services are = distributed, network performance and topology is dynamic and end-users = are mobile. The QNAMEs involved might be user-specific and designed to = trigger cache-misses (e.g. incorporating pseudo-random 64-character = labels), e.g. because there is some user-specific behaviour that is = incorporating the resolution process as a communications channel, or for = reasons of traffic-engineering as described in the enterprise DNS = commentary above, or because it's more reliable than using low TTLs, or = something like that.

By the time an application's engagement with a service enters = this phase, the opportunity to block the engagement has passed. The = nature of the name resolution that exists within this phase is therefore = potentially less contentious than in the initialisation phase. The = communications channels between the application and the service endpoint = have been authenticated at this point, and so to some degree the same = trust that the application puts in those channels for other objects = might also apply to name resolution.

As a thought experiment, perhaps a = particular web service is easier to manage if all the resolution in the = established phase happens inside the same HTTPS bundle that carries HTML = and other objects; performance measurements executed in javascript in a = browser could be shared with the service provider which could then push = user-specific names to optimise service performance and that process = might be architecturally cleaner and cheaper than using the more = circuitous approach necessary with enterprise DNS services. The control = points mentioned in the initialisation phase are unavailable in this = case, but perhaps that's ok.

Even without such sophisticated = resolution requirements, making the service provider directly = responsible for the name resolution involved in using their service = eliminates some attack vectors, e.g. the chance that some required = resolution in this established phase might be hijacked by a third party = as part of a phishing attack.

-- Termination Phase --

For many web services = this seems like it is probably a noop, but it seems wrong not to include = it by way of acknowledging that all good things must surely = end.


Joe

= --Apple-Mail=_B4FBFDEA-672A-4F7A-8D3F-3B5779EFD61C-- --Apple-Mail=_E58B2E4D-67BB-4388-9F31-C96D3FB0E503 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXVWOKQAKCRA0jwy9hlI6 LOUPAJ42nvyhBK13STEm6tMV7Y8/qRXbDwCfR0S/f1fmj+In2+5VQFcm8bVeUvM= =+eF7 -----END PGP SIGNATURE----- --Apple-Mail=_E58B2E4D-67BB-4388-9F31-C96D3FB0E503-- From nobody Thu Aug 15 10:58:16 2019 Return-Path: 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 88DA11200EB for ; Thu, 15 Aug 2019 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Gz8esMeCdfF2 for ; Thu, 15 Aug 2019 10:58:11 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82ED1200FB for ; Thu, 15 Aug 2019 10:58:10 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id s21so876697ioa.1 for ; Thu, 15 Aug 2019 10:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kotho2NwstlcBWfurCZLiBhrYbvadihFTabnqyYKzhk=; b=pVBRiI8pMuFVIxeLjSysgLBb0Sh5EEDSZOeJQkD5lx6caEFjAJTOIiXwcXs6BJ0f85 eISjYiB/hBdcy24swZDL0iz7JkVnlF3EoelMhFB7qe1DDeXC0LfxuJPUQLh7XxCatecR 3y8Z926oO75/ZPMSXqB1t5BPr5NkAIf4ZSyVbyikC1FK6m9fh2zyO/h1nhm2FFKvf7Dp CzzoovQxfV14dYnVSvGoEf262/F61uDKpDzzKPkRDtT9qxBJWNZkaEgSnawF0fRDiILo 8GwdpUPMPSZjCzhB9pwbCCS9EBoXqJwc0teia+0RQQ5QQMAWc64HZlfMziQwF0M/+dOp aGeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kotho2NwstlcBWfurCZLiBhrYbvadihFTabnqyYKzhk=; b=s4i3KpLthiuIkWWrOTB4/lhqtzoxcQ0P9tEO19uBjcTVBqh+krBdckfqliDMPO148g 4FA39+xqHv1Rtxunv3JS9wvUtRtN59nF2BcHq7Teh2FccAY6KXknl7B7QResmjktNo3V zFxyMRk3fdpOWEkz/QoJ8A7LvSnMzX+q/WPfqFj5fU3vp7R3QqYmwh+uMCxni95YVjXc hw5heMuK/j3cA9axv0N/hWkSwdiwRY8q1hW1IYG03CT+ayDsDP1icavCXzoq07PHz0op ZdI1N4Buzg9qQzM5ksHGEVkis+l35dgMmKNDk8HTT6NzD7JlduIpu6g7JOicn0/7b+6m goQw== X-Gm-Message-State: APjAAAWftCD5jdKpT5ypsCIWCwEjKI8cxAQyeXrqs9SG4j1cQQhBytww Ggc+OSHIMypnFVFwab3uyPwHhPQoiOAZWOye9es= X-Google-Smtp-Source: APXvYqw57BB1QJIxTKrmF+e1GumjGHnzNGCYwVPi7zFLkbwVgRUwjNQa9s1zxcIV7y63u8W9Wz8kjtFJa0Wmcg+xVrI= X-Received: by 2002:a5e:c113:: with SMTP id v19mr5044766iol.219.1565891889714; Thu, 15 Aug 2019 10:58:09 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> In-Reply-To: <20190815163938.CF9CB85D108@ary.local> From: Ted Hardie Date: Thu, 15 Aug 2019 10:57:42 -0700 Message-ID: To: John Levine Cc: resolverless-dns@ietf.org, Ben Schwartz Content-Type: multipart/alternative; boundary="000000000000d7d8e005902b9d36" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 17:58:15 -0000 --000000000000d7d8e005902b9d36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy John, On Thu, Aug 15, 2019 at 9:39 AM John Levine wrote: > In article < > CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> you > write: > >-=3D-=3D-=3D-=3D-=3D- > >-=3D-=3D-=3D-=3D-=3D- > > > >Thanks for conducting this investigation, Erik! > > > >In my view, the two main concerns with resolverless architectures have > been > >(1) simplifying stolen key attacks and (2) potential interference with > >DNS-based load balancing. > > I also like the paper but it misses the largest concern with > resolverless DNS: it circumvents DNS based access controls. I realize > this is not a popular position in the IETF, but there are lots of > perfectly good reasons that networks provide filtered DNS. I think it is important to distinguish between networks providing filtering DNS and networks requiring use of their DNS filters. As far as I can tell, no one seems to object to providing filtered DNS either in a local resolver, in a pass-through to an off-premises service, or as a local configuration to the off-premises service. The tussle seems to be instead of whether passing through that control surface is mandatory for clients. We all seem to realize that it was never mandatory for the sophisticated user (/etc/hosts and its friends are a thing, as you imply below), but folks are concerned that if it should become widely available that the situation would change in some deleterious way. Among those posited are: * new opportunities for circumvention for malware * increased likelihood for inappropriate exposure to distressing content (whether for adults or children) * new risks for regulatory or common imposition of other control surfaces There is a further assumption that these risk go up as the level of sophistication for circumvention goes down. I think many of these are predicated on an assumption that the non-local DNS has no filters, which I do not believe has been that well demonstrated; certainly many off-premise services are there specifically to filter for the customers who configure their services. But that filtering highlights the other risks: * new opportunity for a malicious configured service to provide false data to non-DNSSEC validating hosts or applications. * no opportunities for external services to provide access to split-DNS internal data. From my perspective, the push-based DNS record approach is most risky for this latter set of risks. The document currently says: First, clients are only allowed to send application data over an > established connection if they validated the server=E2=80=99s identity vi= a a > server authentication mechanism or a fallback DNS lookup. Figure 2 > presents the validation strategy applied by user agents on DNS records re= trieved > via resolver-less DNS > I can't reproduce the diagram here, but my reading is that you can use this DNS data if you have cached TLS resumption ticket or equivalent; in that case, you can start the 0-RTT exchange knowing the other side will be able to see the application data only if they have the right cryptographic materials. This misses the risk that establishing a connection may leak private information*. It also create a new, fun dependency in the already confusing interaction of cache lifetimes. The DoH style method creates an interdependence between DNS TTL and HTTP cache lifetimes; this creates one with the ticket lifetime. RFC 5077 says this: A client SHOULD delete the ticket and associated state when the time exp= ires. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter or longer period of time than what is stated in the ticket_lifetime_hint. If you know a server sets 0 or a long lifetime, in other words, you may be able to guess that a session ticket is available, but otherwise it is a crapshoot either for the benign DNS-record supplying host or an attacker. Given the large number of cases that will have to follow fallback DNS lookup for the authentication, I think this a useful building block only for very popular services (since they are likely to be in the cache). Given the other resources they have and the reputational risk of allowing random sites to provide DNS records related to them, I'm not yet sure that this is worth it. Ted *Imagine you are a government which wishes to detect when citizens use GRINDR, as you disapprove of same sex encounters. You can have government and affiliated sites push GRINDR DNS records using this method; when someone with a fresh TLS ticket for GRINDR tries to connect, you get their IP address and whatever other data leaked in the exchange. You can limit this risk in various ways (e.g. by requiring the presented TLS certificate of the DNS-record supplying host have the domain in its list of alternative names), but this limits the effectiveness of this method and also runs the risk that governments may have root certificates that can generate those. Even > though it has usually been technically easy to circumvent, most people > don't and it's been good enough. If it's widely circumvented, we can > expect much more intrusive filtering with a lot more collateral damage. > > R's, > John > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --000000000000d7d8e005902b9d36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy John,

=
On Thu, Aug 15, 2019 at 9:39 AM John = Levine <johnl@taugh.com> wrote= :
In article <= ;CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Fa= mu2+SV8g@mail.gmail.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>-=3D-=3D-=3D-=3D-=3D-
>
>Thanks for conducting this investigation, Erik!
>
>In my view, the two main concerns with resolverless architectures have = been
>(1) simplifying stolen key attacks and (2) potential interference with<= br> >DNS-based load balancing.

I also like the paper but it misses the largest concern with
resolverless DNS: it circumvents DNS based access controls.=C2=A0 I realize=
this is not a popular position in the IETF, but there are lots of
perfectly good reasons that networks provide filtered DNS.=C2=A0

I think it is important to distinguish between networ= ks providing filtering DNS and networks requiring use of their DNS filters.= =C2=A0 As far as I can tell, no one seems to object to providing filtered D= NS either in a local resolver, in a pass-through to an off-premises service= , or as a local configuration to the off-premises service.=C2=A0=C2=A0 The = tussle seems to be instead of whether passing through that control surface = is mandatory for clients.=C2=A0

We all seem t= o realize that it was never mandatory for the sophisticated user (/etc/host= s and its friends are a thing, as you imply below), but folks are concerned= that if it should become widely available that the situation would change = in some deleterious way.=C2=A0 Among those posited are:

* new opportunities for circumvention for malware
* increas= ed likelihood for inappropriate exposure to distressing content (whether fo= r adults or children)
* new risks for regulatory or common imposi= tion of other control surfaces

There is a further = assumption that these risk go up as the level of sophistication for circumv= ention goes down.=C2=A0 I think many of these are predicated on an assumpti= on that the non-local DNS has no filters, which I do not believe has been t= hat well demonstrated; certainly many off-premise services are there specif= ically to filter for the customers who configure their services.=C2=A0 But = that filtering highlights the other risks:

* new o= pportunity for a malicious configured service to provide false data to non-= DNSSEC validating hosts or applications.
* no opportunities f= or external services to provide access to split-DNS internal data.

=C2=A0From my perspective, the push-based DNS record a= pproach is most risky for this latter set of risks.=C2=A0 The document curr= ently says:

Firs= t, clients are only allowed to send application data over an established co= nnection if they validated the server=E2=80=99s identity via a server authentication= mechanism or a fallback DNS lookup. Figure 2 presents the validation strategy appli= ed by user agents on DNS records retrieved via resolver-less DNS

I can't reproduce the diagram here, but my re= ading is that you can use this DNS data if you have cached TLS resumption t= icket or equivalent; in that case, you can start the 0-RTT exchange knowing= the other side will be able to see the application data only if they have = the right cryptographic materials.=C2=A0 This misses the risk that establis= hing a connection may leak private information*.=C2=A0 It also create a new= , fun dependency in the already confusing interaction of cache lifetimes.= =C2=A0 The DoH style method creates an interdependence between DNS TTL and = HTTP cache lifetimes; this creates one with the ticket lifetime.=C2=A0 RFC = 5077 says this:
   A client SHOULD d=
elete the ticket and associated state when the time expires.
   It MAY delete the ticket earlier based on local policy.  A server MAY
   treat a ticket as valid for a shorter or longer period of time than
   what is stated in the ticket_lifetime_hint.
If you know = a server sets 0 or a long lifetime, in other words, you may be able to gues= s that a session ticket is available, but otherwise it is a crapshoot eithe= r for the benign DNS-record supplying host or an attacker.=C2=A0
=

Given the large number of cases that will have to follo= w fallback DNS lookup for the authentication, I think this a useful buildin= g block only for very popular services (since they are likely to be in the = cache).=C2=A0 Given the other resources they have and the reputational risk= of allowing random sites to provide DNS records related to them, I'm n= ot yet sure that this is worth it.

Ted
<= br>
*Imagine you are a government which wishes to detect when cit= izens use GRINDR, as you disapprove of same sex encounters.=C2=A0 You can h= ave government=C2=A0 and affiliated sites push GRINDR DNS records using thi= s method; when someone with a fresh TLS ticket for GRINDR tries to connect,= you get their IP address and whatever other data leaked in the exchange.= =C2=A0 You can limit this risk in various ways (e.g. by requiring the prese= nted TLS certificate of the DNS-record supplying host have the domain in it= s list of alternative names), but this limits the effectiveness of this met= hod and also runs the risk that governments may have root certificates that= can generate those.


Even
though it has usually been technically easy to circumvent, most people
don't and it's been good enough.=C2=A0 If it's widely circumven= ted, we can
expect much more intrusive filtering with a lot more collateral damage.

R's,
John

--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--000000000000d7d8e005902b9d36-- From nobody Thu Aug 15 12:00:48 2019 Return-Path: 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 63343120888 for ; Thu, 15 Aug 2019 12:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 EAL88c5lzsja for ; Thu, 15 Aug 2019 12:00:37 -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 3F9D712080D for ; Thu, 15 Aug 2019 12:00:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 1A172C28 for ; Thu, 15 Aug 2019 21:00:35 +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 dCavokhxiEIS for ; Thu, 15 Aug 2019 21:00:33 +0200 (CEST) Received: from users-MBP.fritz.box (mue-88-130-80-179.dsl.tropolys.de [88.130.80.179]) (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 6CA89C27 for ; Thu, 15 Aug 2019 21:00:33 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190815163938.CF9CB85D108@ary.local> From: Erik Sy 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: <8a8754b1-c646-34fc-a13b-d69757b807f3@informatik.uni-hamburg.de> Date: Thu, 15 Aug 2019 21:00:31 +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: <20190815163938.CF9CB85D108@ary.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070602030903020509010702" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 19:00:47 -0000 This is a cryptographically signed message in MIME format. --------------ms070602030903020509010702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi John, On 8/15/19 18:39, John Levine wrote: > > I also like the paper but it misses the largest concern with > resolverless DNS: it circumvents DNS based access controls. Resolver-less DNS does not circumvent DNS-based access controls. First, clients can configure their user agent to filter the DNS records retrieved via resolver-less DNS to enforce such access controls. Second, resolver-less DNS requires in some situations fallback DNS queries using the traditional resolver that may conduct DNS-based access controls. Erik --------------ms070602030903020509010702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTUxOTAwMzFaMC8GCSqGSIb3DQEJBDEiBCAlyxLhBXWe MFB1M6EjNAh28LB/7MSeIlQGz10+vdSyuTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBtEKwbTGqmxAqrKCMPvt2DEVzhBQa6m7X+b0Ig 6/NvyWMvkOeh2RiBjCiHW8Ld8fAKNuVSXoJe2uo9xmpFGDL/SuLE35hX3oXnWaU8/BJhXtGa j8S7QBVxWKPlYLpkTXY/Tz9LKK9fbwQPOqU9K58nPUXhTWzFm9Z8sI4SIYxno/0r787HS+iw xp5HUKW0k9dBrUEgRytD4wT1DnZ4ibiDJNF5FxsZooPnQKAT4fmp6gTYvGbYo6jlg6SxVplA UXsw7SBzkfbALAIOtUSDLoIhS4ZDyv9hQtakjCdnpY0BHz9/l3bh4eS/0aFAh5WjB0k9K+jY /SgIIetmQBMn0W/8AAAAAAAA --------------ms070602030903020509010702-- From nobody Thu Aug 15 12:09:22 2019 Return-Path: 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 F138B120127 for ; Thu, 15 Aug 2019 12:09:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=h3YF6hGG; dkim=pass (1536-bit key) header.d=taugh.com header.b=Fg8u9pbX 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 FPQq3GemMU88 for ; Thu, 15 Aug 2019 12:09:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6D0EA120122 for ; Thu, 15 Aug 2019 12:09:17 -0700 (PDT) Received: (qmail 40997 invoked from network); 15 Aug 2019 19:09:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=a022.5d55addc.k1908; i=johnl-iecc.com@submit.iecc.com; bh=RsbS2LUXDkLkyFxqxRPmxyEMFe3O0J1xKj9uBCg3ggU=; b=h3YF6hGGGVBwEGZu5UHbMkrAEZJo0dyRRneThe1EHkNmkRhA3rEfk8NqWy7dyoSP8s2cDhsUB9R9QBJXmXUbbzqP07qDVPlfd0MMlJofI3SoD3SDcjCYmF69gshC3sPuDPDNv7RpKbw5KaI4YAlDxMKy5iC06NsjUS1QTewgwFU/bRjQ9NcqlSL+LTUGEh9ZHHYcoh1eL1Ap89I5m3JDB+bxI+eEP1J9zct+U0YgCJaRxioYqQmhhiHuoJSC/oTy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=a022.5d55addc.k1908; olt=johnl-iecc.com@submit.iecc.com; bh=RsbS2LUXDkLkyFxqxRPmxyEMFe3O0J1xKj9uBCg3ggU=; b=Fg8u9pbXx18Ato8kso+Q7M7Dp9GYITsOCpIy4x9TWrh2vA5JC06AwTe3e5ulZJvy0UXr0WypE1FaLQtxFXnmgJzufrX5jbtCL/GafgNX/Pdn5yDCOOzCfUkmzLz+sT72o6K6Bu6KKqz/WnxZjAl4bISo3zkoFJjDCqc4js3W9VDiU+G0ymAk7zRuwFYfhJpiy5RWDnHDDtNLVmWrmM78wPt39Zi1iy+Y7/0yGLurTtpD4gzyh4zXcJHfwQquR4iR Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 15 Aug 2019 19:09:16 -0000 Date: 15 Aug 2019 15:09:15 -0400 Message-ID: From: "John R Levine" To: "Ted Hardie" Cc: resolverless-dns@ietf.org In-Reply-To: References: <20190815163938.CF9CB85D108@ary.local> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-ID: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 19:09:20 -0000 I think I've seen rants that any interference with true DNS is evil (add DNSSEC to suit) but I think we can agree they're in the weeds. > [ possible badness ] are: > > * new opportunities for circumvention for malware > * increased likelihood for inappropriate exposure to distressing content > (whether for adults or children) > * new risks for regulatory or common imposition of other control surfaces Not just distressing. A lot of networks are inside organizations, and they have policy reasons to limit what things their employees can see, e.g., porn and gambling, or perhaps competitor's web sites if there's a risk of anti-competive collusion. I've seen networks that force all outgoing port 53 traffic to their own resolver to more or less transparently enforce the policy. > There is a further assumption that these risk go up as the level of > sophistication for circumvention goes down. I think many of these are > predicated on an assumption that the non-local DNS has no filters, ... Not at all, it's that the non-local DNS doesn't have the policy filters that the local DNS does. > * new opportunity for a malicious configured service to provide false data > to non-DNSSEC validating hosts or applications. > * no opportunities for external services to provide access to split-DNS > internal data. That, too. But the key point is that many networks do policy filtering and other people's DNS is unlikely to implement the same policy. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 15 12:22:22 2019 Return-Path: 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 BEB561200F8 for ; Thu, 15 Aug 2019 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 cEzw8PgWYBka for ; Thu, 15 Aug 2019 12:22:19 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A5120114 for ; Thu, 15 Aug 2019 12:22:17 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B3977892E8; Thu, 15 Aug 2019 19:22:17 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Thu, 15 Aug 2019 19:22:16 +0000 Message-ID: <2017170.mVuLTY5bmt@linux-9daj> Organization: none In-Reply-To: <8a8754b1-c646-34fc-a13b-d69757b807f3@informatik.uni-hamburg.de> References: <20190815163938.CF9CB85D108@ary.local> <8a8754b1-c646-34fc-a13b-d69757b807f3@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 19:22:21 -0000 On Thursday, 15 August 2019 19:00:31 UTC Erik Sy wrote: > Hi John, > > On 8/15/19 18:39, John Levine wrote: > > I also like the paper but it misses the largest concern with > > resolverless DNS: it circumvents DNS based access controls. > > Resolver-less DNS does not circumvent DNS-based access controls. First, > clients can configure their user agent to filter the DNS records > retrieved via resolver-less DNS to enforce such access controls. how? right now network operators use DNS RPZ, implemented in their recursive name servers, to achieve multivendor threat intelligence based policy enforcement at the DNS level. i know of no similar protocol by which browsers could learn the network operator's policy. and in any case some of the policy rules expressed in RPZ are about name server names and name server addresses, neither of which a browser will know. so, this _does_ circumvent, as written, and i suspect, by (poltiical) intent. > Second, > resolver-less DNS requires in some situations fallback DNS queries using > the traditional resolver that may conduct DNS-based access controls. that's small beer, irrelevant to the thread. -- Paul From nobody Thu Aug 15 13:13:48 2019 Return-Path: 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 0B05E1200CC for ; Thu, 15 Aug 2019 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 G0TgAT5qzSaZ for ; Thu, 15 Aug 2019 13:13:44 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD99712007C for ; Thu, 15 Aug 2019 13:13:43 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id g17so3306301wrr.5 for ; Thu, 15 Aug 2019 13:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ha+OZlJ5KFkeL/s3fKphvME3dQrXp0vwQ8J08v2AETU=; b=ZbO21nHL9x+gDnUl9SIM5JsqSN8FA36TFmLgoJTfGfJXjAyANGPJIDoi4l2kK5zM36 0hKkz/njl5g4WlOm8fWlQy6mNRuL/JNaowyC2Ov27byZs6ZZt+aOgtbnj+f2TknEXbSr pzM91etCyloZEE5886lr7Lzubhh4wHF6v1P0loaiSp/YW5PJQb5u+MbB10Eb4MkStF5J HXFAO1sQ7BJa7HlBERlTBZedWJ1JEL01F/FuLDnqcHV7au1E+FS7riFGujD/7K+lS05b WMKAdvXjGHL4RWtfeRf0GqxmyuBfVJ46bs+o6NJeylsgHKgcOub523nZUkAtw8jQ3ILa FVmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ha+OZlJ5KFkeL/s3fKphvME3dQrXp0vwQ8J08v2AETU=; b=MoOywq+3CIc4YhCTsVP3ADvVBCb6APtiLKLO+Xt4ucYybFC7gP7QuZox6tAPygYpoi jzh07t6yt687wVbkhQskCjIdWzQ8MgBY+UtLhyY531YN8LpJmlEXjEV2OzMzJMEzY1rv 6rUDgSlY0lS9bH72dzcn4092sm2OawZjnKFqRENO8RbBHraYTxNOrBneExdFeCbTWuCb LB9H9/i2C/zwZurqFYaMfpb3STBIxruGrRRIeoJrYDQE6qqx/VouEIjCJ9J/l2Ik7N2g jCQacPQGn4Zt61fNf3mR7584hSg2/PyhxgWtaZ6IzQIsOHsdg8q0y07YAOasK64CXZdG Xk5g== X-Gm-Message-State: APjAAAXfXEyyglOXu89V3yRMInZe714Abwui3uETDifE9VDyjUFFhMOt wS0dVSiCMJqcJifvfWO607Wdj1cP3wa+ot2L10oEaw== X-Google-Smtp-Source: APXvYqxAjJFU8ts5QHkC03wO3JLnCVxmDDHBZz1TtnhbYWZIETmpXbgAXaCdGHPrqvRnYsBlv710qC2IJN2UAnhGxw0= X-Received: by 2002:a5d:634c:: with SMTP id b12mr6883693wrw.127.1565900021920; Thu, 15 Aug 2019 13:13:41 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> In-Reply-To: <20190815163938.CF9CB85D108@ary.local> From: Eric Orth Date: Thu, 15 Aug 2019 16:13:30 -0400 Message-ID: To: John Levine Cc: resolverless-dns@ietf.org, Ben Schwartz Content-Type: multipart/alternative; boundary="0000000000008fde3905902d82b5" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 20:13:46 -0000 --0000000000008fde3905902d82b5 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 15, 2019 at 12:39 PM John Levine wrote: > I also like the paper but it misses the largest concern with > resolverless DNS: it circumvents DNS based access controls. I realize > this is not a popular position in the IETF, but there are lots of > perfectly good reasons that networks provide filtered DNS. Even > though it has usually been technically easy to circumvent, most people > don't and it's been good enough. If it's widely circumvented, we can > expect much more intrusive filtering with a lot more collateral damage. > >From the Chrome perspective, this is a concern I partly share. I'm mostly ignoring here the circumvention and forced-filtering issues of whether or not the network should be able to mandate filtering/manipulation or whether or not clients should be forced to comply with such things because that issue is being debated enough over in the ADD mailing list. But if Chrome is using a particular filtering DNS server, especially if that server has been explicitly selected by the user or someone with authority over the user's device, seems like it would result in a bad user experience if we then bypassed that filtering by retrieving results outside the DNS server. My initial thinking is that we would then ideally only use resolverless DNS if we had knowledge that the in-use recursive resolver is not doing significant filtering. But such a signal does not currently generally exist, so would we be limited to only doing resolverless DNS when the resolver is on a hardcoded list of non-filtering resolvers? --0000000000008fde3905902d82b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2019 at 12:39 PM John Lev= ine <johnl@taugh.com> wrote:
I also like the paper but it misses the largest concern with
resolverless DNS: it circumvents DNS based access controls.=C2=A0 I realize=
this is not a popular position in the IETF, but there are lots of
perfectly good reasons that networks provide filtered DNS.=C2=A0 Even
though it has usually been technically easy to circumvent, most people
don't and it's been good enough.=C2=A0 If it's widely circumven= ted, we can
expect much more intrusive filtering with a lot more collateral damage.
=

From the Chrome perspective, this is a con= cern I partly share.=C2=A0 I'm mostly ignoring here the circumvention a= nd forced-filtering issues of whether or not the network should be able to = mandate filtering/manipulation or whether or not clients should be forced t= o comply with such things because that issue=C2=A0is being debated enough o= ver in the ADD mailing list.

But if Chrome is usin= g a particular filtering DNS server, especially if that server has been exp= licitly selected by the user or someone with authority over the user's = device, seems like it would result in a bad user experience if we then bypa= ssed that filtering by retrieving results outside the DNS server.=C2=A0 My = initial thinking is that we would then ideally only use resolverless DNS if= we had knowledge that the in-use recursive resolver is not doing significa= nt filtering.=C2=A0 But such a signal does not currently generally exist, s= o would we be limited to only doing resolverless DNS when the resolver is o= n a hardcoded list of non-filtering resolvers?
--0000000000008fde3905902d82b5-- From nobody Thu Aug 15 13:25:34 2019 Return-Path: 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 0367D1200CC for ; Thu, 15 Aug 2019 13:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 fRb4U3zDfS5B for ; Thu, 15 Aug 2019 13:25:29 -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 D9BCE1200C7 for ; Thu, 15 Aug 2019 13:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E7E6156 for ; Thu, 15 Aug 2019 22:25:26 +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 Sm-+PNj0+DLX for ; Thu, 15 Aug 2019 22:25:26 +0200 (CEST) Received: from users-MBP.fritz.box (mue-88-130-80-179.dsl.tropolys.de [88.130.80.179]) (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 4B99C54 for ; Thu, 15 Aug 2019 22:25:24 +0200 (CEST) From: Erik Sy To: resolverless-dns@ietf.org References: <20190815163938.CF9CB85D108@ary.local> 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: Date: Thu, 15 Aug 2019 22:25:23 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010705030108080503050101" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 20:25:32 -0000 This is a cryptographically signed message in MIME format. --------------ms010705030108080503050101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Ted, On 8/15/19 19:57, Ted Hardie wrote: > =C2=A0From my perspective, the push-based DNS record approach is most r= isky > for this latter set of risks.=C2=A0 The document currently says: > > First, clients are only allowed to send application data over an > established connection ifthey validated the server=E2=80=99s identi= ty via > a server authentication mechanism or a fallback DNS lookup. Figure > 2 presents the validation strategy applied by user agents on DNS > records retrieved via resolver-less DNS > > > I can't reproduce the diagram here, but my reading is that you can use > this DNS data if you have cached TLS resumption ticket or equivalent; > in that case, you can start the 0-RTT exchange knowing the other side > will be able to see the application data only if they have the right > cryptographic materials.=C2=A0 This misses the risk that establishing a= > connection may leak private information*. The problem you are describing is not introduced by resolver-less DNS. A traditional DNS resolver can conduct the exact same attack by distributing fake DNS records and observe the client's connection establishment. > =C2=A0 It also create a new, fun dependency in the already confusing > interaction of cache lifetimes.=C2=A0 The DoH style method creates an > interdependence between DNS TTL and HTTP cache lifetimes; this creates > one with the ticket lifetime. I feel like you possibly misunderstood the validation strategy. I proposed an opportunistic approach, where the client always attempts a connection establishments towards the IP address retrieved via resolver-less DNS. Subsequently, if the connection does not provide server authentication, the client evaluates a fallback DNS record retrieved via the traditional DNS. Thus, I do not understand why an interdependence with the ticket lifetime is created. Erik=C2=A0 > =C2=A0 RFC 5077 says this: > A client SHOULD delete the ticket and associated state when the time= expires. > It MAY delete the ticket earlier based on local policy. A server MA= Y > treat a ticket as valid for a shorter or longer period of time than > what is stated in the ticket_lifetime_hint. > If you know a server sets 0 or a long lifetime, in other words, you > may be able to guess that a session ticket is available, but otherwise > it is a crapshoot either for the benign DNS-record supplying host or > an attacker.=C2=A0 > > Given the large number of cases that will have to follow fallback DNS > lookup for the authentication, I think this a useful building block > only for very popular services (since they are likely to be in the > cache).=C2=A0 Given the other resources they have and the reputational = risk > of allowing random sites to provide DNS records related to them, I'm > not yet sure that this is worth it. > > Ted > > *Imagine you are a government which wishes to detect when citizens use > GRINDR, as you disapprove of same sex encounters.=C2=A0 You can have > government=C2=A0 and affiliated sites push GRINDR DNS records using thi= s > method; when someone with a fresh TLS ticket for GRINDR tries to > connect, you get their IP address and whatever other data leaked in > the exchange.=C2=A0 You can limit this risk in various ways (e.g. by > requiring the presented TLS certificate of the DNS-record supplying > host have the domain in its list of alternative names), but this > limits the effectiveness of this method and also runs the risk that > governments may have root certificates that can generate those. > > --------------ms010705030108080503050101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTUyMDI1MjRaMC8GCSqGSIb3DQEJBDEiBCBEW1/JDW0z ROjyDRyXHjkUCyMqmezWNbENxmsjpEwmCzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBl1C7oYw0LdB60/ZOnmWoc4b0Tsl+tRpNXFCgV ZI0fd4W2ZU9GNmKFC4rldvCv9/jf9Vb89J5yQYJ3UYiLwCj6f2q3qMPpvjawjvtpz+CEy4iK Jc38H20zq5UEPu9Okls9a+ZP0Q3omDWOBJVxeK+1GcfEqOoK0sY14fWKi3oYRnUFB8/rniOp EqZzPmMnKEd/3j4mT7sH8nDyFWGAE4DzwLQv0fsSiz1oGu8/QjeZ0ggJdg2DGqjXrlm04xyQ 4rafh/traA1gg+dWd6lI23ZMdAtKoukQu+mhrSEdiCnHKyKdu+9w9qp/TSxW6uMXcO51d6NY vEQS3Qtv+f0+iLNmAAAAAAAA --------------ms010705030108080503050101-- From nobody Thu Aug 15 14:03:50 2019 Return-Path: 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 5B2321200DB for ; Thu, 15 Aug 2019 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uvNWeoVUfvLg for ; Thu, 15 Aug 2019 14:03:45 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A831D1200C7 for ; Thu, 15 Aug 2019 14:03:45 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id q22so1994166iog.4 for ; Thu, 15 Aug 2019 14:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BpUHEE2wS40UjAyPqKpkfovX492JesU0uh1b0UPMdmE=; b=EzwvYefuaVkcCJMgekthbowemMlT3AUIgl8Kx/guWujtF9YLsGCueiIEMsy+M5Eo4z zzpt/iUCE09WnWkzznUxMyKpgeTlodT1hE0RvfEeIGiOiOlMh/kgJL/SNXyEbVpKld6R ZBsywvvn4Sgf2Zp4qQGZOF8kl8uvhIWlCbJCd2WzuFhBRj6qrlXcL1uw8Hk0SVFZw2Fh RrCTb/tB5cXaRZhZnzfEsLYIMRfVL9ytVWgueOg+/ybYv0Ogyp6lDNZBFdvgTedRujjG 23qWofIKyOwU7gWtqk6Qx0qQ/uFHwXMv3IBpef6HgPjVPijQgsRpAUPpOzR+iR2fxklI JpIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BpUHEE2wS40UjAyPqKpkfovX492JesU0uh1b0UPMdmE=; b=Q1JS+d3BkydUkxVdxTuBWHxdRrHPJXz0eZr+5T9sISCRgZPphOMdAdYisSE2e7f7Wy 082sW58s5NhzuQTz+tbWxdav2MliJ0dofbDolbGxstwSFzndtzfzztTiTCo2GZ6dTbxZ Yo5KVdDQTUI7FP+JYgHhijmhWXZf/IdeY0yCyjZM1p2/gPyFNzNfM+9ISVWHmxcO6TH6 7E28TP82p3WfebwWx3/37tg/SsJzZiKelMQTGVQvYviHFxLA1OUzrHyw31hM77YpmLN8 TkdqvT9ZzKGm8p1QbR8Dr/iS4IqSyB+KWyZwinMUCYiiZmU3Yg9ZzQ8VEGWTQPDqZJFt ETog== X-Gm-Message-State: APjAAAWR78i5HJlvabNQ5sB6oR27FlOGcqCPssAAq3VWDuNSi4TdSOkK E512Xop0K5df+ilj6Vv0OjRbZlpop1dD9wfKMDo= X-Google-Smtp-Source: APXvYqzyulwkhKrswstDGWkJOOnMO+SFpPOo7z6mZeSLprNS6RFUPt4cjwLiY+81o5yoVMDE7Hm/biuM0E3d0BYaCQw= X-Received: by 2002:a05:6602:22ce:: with SMTP id e14mr7572778ioe.290.1565903024606; Thu, 15 Aug 2019 14:03:44 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> In-Reply-To: From: Ted Hardie Date: Thu, 15 Aug 2019 14:03:17 -0700 Message-ID: To: sy@informatik.uni-hamburg.de Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="00000000000088dd0205902e35be" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 21:03:49 -0000 --00000000000088dd0205902e35be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Erik, Thanks for your reply. On Thu, Aug 15, 2019 at 1:25 PM Erik Sy wrote: > Hi Ted, > > On 8/15/19 19:57, Ted Hardie wrote: > > From my perspective, the push-based DNS record approach is most risky > > for this latter set of risks. The document currently says: > > > > First, clients are only allowed to send application data over an > > established connection ifthey validated the server=E2=80=99s identi= ty via > > a server authentication mechanism or a fallback DNS lookup. Figure > > 2 presents the validation strategy applied by user agents on DNS > > records retrieved via resolver-less DNS > > > > > > I can't reproduce the diagram here, but my reading is that you can use > > this DNS data if you have cached TLS resumption ticket or equivalent; > > in that case, you can start the 0-RTT exchange knowing the other side > > will be able to see the application data only if they have the right > > cryptographic materials. This misses the risk that establishing a > > connection may leak private information*. > > The problem you are describing is not introduced by resolver-less DNS. A > traditional DNS resolver can conduct the exact same attack by > distributing fake DNS records and observe the client's connection > establishment. > > Agreed, but your proposal appears as written to allow any web server to try the attack, where it was formerly limited to a configured resolver. Unless I misunderstand the proposal, that a significant change in attack surface. > > It also create a new, fun dependency in the already confusing > > interaction of cache lifetimes. The DoH style method creates an > > interdependence between DNS TTL and HTTP cache lifetimes; this creates > > one with the ticket lifetime. > > I feel like you possibly misunderstood the validation strategy. I > proposed an opportunistic approach, where the client always attempts a > connection establishments towards the IP address retrieved via > resolver-less DNS. You're right, I misread it. I thought you were saying that the client should try only in the case where it had the TLS resumption ticket and should fall back *before attempting the resolution* otherwise. You may want to update the text pointing to Figure 2 or Figure 2 to make that clearer. > Subsequently, if the connection does not provide > server authentication, the client evaluates a fallback DNS record > retrieved via the traditional DNS. This seems to indicate that the attack I mentioned earlier is much easier to mount as both tracks in Figure 2 allow it. It also raises the risk that a client will receive a server authentication from a CA not intended by the domain owner (our friend the enterprise, an attacker, a government, etc.). We have some mitigations for that, but they are not complete. Unless you somehow limit the number of domains a web server can provide DNS records for in some way that approximately matches their own URL authority, this seems fairly risky to me. You can eliminate the risk for a DNSSEC validating application if the DNS records allow the validation to occur. But that is not, at least yet, common. regards, Ted Thus, I do not understand why an > interdependence with the ticket lifetime is created. > > > Erik > > > RFC 5077 says this: > > A client SHOULD delete the ticket and associated state when the time > expires. > > It MAY delete the ticket earlier based on local policy. A server MA= Y > > treat a ticket as valid for a shorter or longer period of time than > > what is stated in the ticket_lifetime_hint. > > If you know a server sets 0 or a long lifetime, in other words, you > > may be able to guess that a session ticket is available, but otherwise > > it is a crapshoot either for the benign DNS-record supplying host or > > an attacker. > > > > Given the large number of cases that will have to follow fallback DNS > > lookup for the authentication, I think this a useful building block > > only for very popular services (since they are likely to be in the > > cache). Given the other resources they have and the reputational risk > > of allowing random sites to provide DNS records related to them, I'm > > not yet sure that this is worth it. > > > > Ted > > > > *Imagine you are a government which wishes to detect when citizens use > > GRINDR, as you disapprove of same sex encounters. You can have > > government and affiliated sites push GRINDR DNS records using this > > method; when someone with a fresh TLS ticket for GRINDR tries to > > connect, you get their IP address and whatever other data leaked in > > the exchange. You can limit this risk in various ways (e.g. by > > requiring the presented TLS certificate of the DNS-record supplying > > host have the domain in its list of alternative names), but this > > limits the effectiveness of this method and also runs the risk that > > governments may have root certificates that can generate those. > > > > > > > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --00000000000088dd0205902e35be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

Th= anks for your reply.

On Thu, Aug 15, 2019 at 1:25 PM Erik Sy <<= a href=3D"mailto:sy@informatik.uni-hamburg.de">sy@informatik.uni-hamburg.de= > wrote:
= Hi Ted,

On 8/15/19 19:57, Ted Hardie wrote:
> =C2=A0From my perspective, the push-based DNS record approach is most = risky
> for this latter set of risks.=C2=A0 The document currently says:
>
>=C2=A0 =C2=A0 =C2=A0First, clients are only allowed to send application= data over an
>=C2=A0 =C2=A0 =C2=A0established connection ifthey validated the server= =E2=80=99s identity via
>=C2=A0 =C2=A0 =C2=A0a server authentication mechanism or a fallback DNS= lookup. Figure
>=C2=A0 =C2=A0 =C2=A02 presents the validation strategy applied by user = agents on DNS
>=C2=A0 =C2=A0 =C2=A0records retrieved via resolver-less DNS
>
>
> I can't reproduce the diagram here, but my reading is that you can= use
> this DNS data if you have cached TLS resumption ticket or equivalent;<= br> > in that case, you can start the 0-RTT exchange knowing the other side<= br> > will be able to see the application data only if they have the right > cryptographic materials.=C2=A0 This misses the risk that establishing = a
> connection may leak private information*.

The problem you are describing is not introduced by resolver-less DNS. A traditional DNS resolver can conduct the exact same attack by
distributing fake DNS records and observe the client's connection
establishment.


Agreed, but your proposal appears as w= ritten to allow any web server to try the attack, where it was formerly lim= ited to a configured resolver.=C2=A0 Unless I misunderstand the proposal, t= hat a significant change in attack surface.
=C2=A0
> =C2=A0 It also create a new, fun dependency in the already confusing > interaction of cache lifetimes.=C2=A0 The DoH style method creates an<= br> > interdependence between DNS TTL and HTTP cache lifetimes; this creates=
> one with the ticket lifetime.

I feel like you possibly misunderstood the validation strategy. I
proposed an opportunistic approach, where the client always attempts a
connection establishments towards the IP address retrieved via
resolver-less DNS.

You're right, I mis= read it.=C2=A0 I thought you were saying that the client should try only in= the case where it had the TLS resumption ticket and should fall back *befo= re attempting the resolution* otherwise.=C2=A0 You may want to update the t= ext pointing to Figure 2 or Figure 2 to make that clearer.
= =C2=A0
Subsequently,= if the connection does not provide
server authentication, the client evaluates a fallback DNS record
retrieved via the traditional DNS.

This se= ems to indicate that the attack I mentioned earlier is much easier to mount= as both tracks in Figure 2 allow it.=C2=A0 It also raises the risk that a = client will receive a server authentication from a CA not intended by the d= omain owner (our friend the enterprise, an attacker, a government, etc.).= =C2=A0 We have some mitigations for that, but they are not complete.

Unless you somehow limit the number of domains a web= server can provide DNS records for in some way that approximately matches = their own URL authority, this seems fairly risky to me.=C2=A0=C2=A0 You can= eliminate the risk for a DNSSEC validating application if the DNS records = allow the validation to occur.=C2=A0=C2=A0 But that is not, at least yet, c= ommon.

regards,

Ted


Thus, I do not understand why an
interdependence with the ticket lifetime is created.
<= br>

=C2=A0

Erik=C2=A0

> =C2=A0 RFC 5077 says this:
>=C2=A0 =C2=A0 A client SHOULD delete the ticket and associated state wh= en the time expires.
>=C2=A0 =C2=A0 It MAY delete the ticket earlier based on local policy.= =C2=A0 A server MAY
>=C2=A0 =C2=A0 treat a ticket as valid for a shorter or longer period of= time than
>=C2=A0 =C2=A0 what is stated in the ticket_lifetime_hint.
> If you know a server sets 0 or a long lifetime, in other words, you > may be able to guess that a session ticket is available, but otherwise=
> it is a crapshoot either for the benign DNS-record supplying host or > an attacker.=C2=A0
>
> Given the large number of cases that will have to follow fallback DNS<= br> > lookup for the authentication, I think this a useful building block > only for very popular services (since they are likely to be in the
> cache).=C2=A0 Given the other resources they have and the reputational= risk
> of allowing random sites to provide DNS records related to them, I'= ;m
> not yet sure that this is worth it.
>
> Ted
>
> *Imagine you are a government which wishes to detect when citizens use=
> GRINDR, as you disapprove of same sex encounters.=C2=A0 You can have > government=C2=A0 and affiliated sites push GRINDR DNS records using th= is
> method; when someone with a fresh TLS ticket for GRINDR tries to
> connect, you get their IP address and whatever other data leaked in > the exchange.=C2=A0 You can limit this risk in various ways (e.g. by > requiring the presented TLS certificate of the DNS-record supplying > host have the domain in its list of alternative names), but this
> limits the effectiveness of this method and also runs the risk that > governments may have root certificates that can generate those.
>
>



--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--00000000000088dd0205902e35be-- From nobody Thu Aug 15 15:01:31 2019 Return-Path: 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 220721200C7 for ; Thu, 15 Aug 2019 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bcl8N8Wsu6jV for ; Thu, 15 Aug 2019 15:01:27 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044D91200EC for ; Thu, 15 Aug 2019 15:01:26 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id b1so7860931otp.6 for ; Thu, 15 Aug 2019 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=G5ZwPRB9iaUY5cBWsH2UDIpXr6HVCaw0wbeAGQL+ZVc=; b=T3K6MOMJlIHEHrp1eZReHkxnKPlcNHV7pitTJRp9ec4o2SrjU5uHbCE/QZ+kYKxlrg yL2pgAygfcy2KyU3O2YtpIg4NO3H/D4WQkTYxjYlUIqIMqcWNdfIgRfQFvUtaD+LW5Yo 2g/LuyCaETBTNUVSUZsvWzF12+AjFuoGZZDywSeQ+YHLNBIIg6nEQx9sa01aasA/tCyU lhnd0gNPrphHPCwgq/+Q9xKehl5EJXMj7k9wMshFRoA86VCdJW6Xn3YqnzuA82RJwZ5X G1DDVDH6NhVH7WR2nCUOg2ZaJE9oxK3ST3tfnFqlPr9gzq7zhQCLHAJf6xIjYzkStV56 wUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=G5ZwPRB9iaUY5cBWsH2UDIpXr6HVCaw0wbeAGQL+ZVc=; b=k3uR69gYyJqEUO2dv342k1U43u3pDqANeZrnzcGUas69B3yiUQWWetlK7BpYlCKv3L q89DoSUKsD1s3MXOXiwFtZbuvB+45D9a7WR1LO9OhlrTxBpfdUedr9pwT3VmimXDd/WY CxL7p5K2WdLI5gllAeYY+7uac8mTiSOb9HtWOf+SgeDtjCkunVPGyxDCmN7T1+eQYvFU c0ciqPfK6zFz/XkNBaDUs4ly3OHIyqbbKwvhufK4TTdq/fIaPSgMOn9J00erU/cve6os Qh6xa4/SlF2Dhr+kVdInm9WIlovjI56z9wfagx95lwDsMuFXyNKi4/U+F5kie1WBLQ0v Yrtg== X-Gm-Message-State: APjAAAXEaHlyyTq48iJH6QYm0GkICXjzefqtqyXz9XvZ/dQkw+epcYNs Rl0uzwheafOsZBav7ovnpIU= X-Google-Smtp-Source: APXvYqyjuxHIM+n98HL29LK9EPNKUG7x3V5nUMudIe7nYom7Tutg+p9nKJS+K0iDNRpcUpEX1tzMpQ== X-Received: by 2002:a9d:5911:: with SMTP id t17mr4802690oth.159.1565906486273; Thu, 15 Aug 2019 15:01:26 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1052? ([2600:8802:5903:df16::1052]) by smtp.gmail.com with ESMTPSA id s5sm1398482otk.11.2019.08.15.15.01.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 15 Aug 2019 15:01:25 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-17E27551-4912-4816-BB97-9A4AFDD22795 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Fred Baker In-Reply-To: Date: Thu, 15 Aug 2019 15:01:24 -0700 Cc: John Levine , Ben Schwartz , resolverless-dns@ietf.org Message-Id: References: To: Eric Orth X-Mailer: iPhone Mail (17A5556d) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 22:01:29 -0000 --Apple-Mail-17E27551-4912-4816-BB97-9A4AFDD22795 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One thing I would want to be certain of is that the host did DNSSEC validati= on. It=E2=80=99s the only way I know of to verify the validity of the RR. Sent using a machine that autocorrects in interesting ways... > On Aug 15, 2019, at 1:13 PM, Eric Orth wrote: >=20 > =EF=BB=BF >> On Thu, Aug 15, 2019 at 12:39 PM John Levine wrote: >=20 >> I also like the paper but it misses the largest concern with >> resolverless DNS: it circumvents DNS based access controls. I realize >> this is not a popular position in the IETF, but there are lots of >> perfectly good reasons that networks provide filtered DNS. Even >> though it has usually been technically easy to circumvent, most people >> don't and it's been good enough. If it's widely circumvented, we can >> expect much more intrusive filtering with a lot more collateral damage. >=20 > =46rom the Chrome perspective, this is a concern I partly share. I'm most= ly ignoring here the circumvention and forced-filtering issues of whether or= not the network should be able to mandate filtering/manipulation or whether= or not clients should be forced to comply with such things because that iss= ue is being debated enough over in the ADD mailing list. >=20 > But if Chrome is using a particular filtering DNS server, especially if th= at server has been explicitly selected by the user or someone with authority= over the user's device, seems like it would result in a bad user experience= if we then bypassed that filtering by retrieving results outside the DNS se= rver. My initial thinking is that we would then ideally only use resolverle= ss DNS if we had knowledge that the in-use recursive resolver is not doing s= ignificant filtering. But such a signal does not currently generally exist,= so would we be limited to only doing resolverless DNS when the resolver is o= n a hardcoded list of non-filtering resolvers? > --=20 > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns --Apple-Mail-17E27551-4912-4816-BB97-9A4AFDD22795 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable One thing I would want to be certain of is t= hat the host did DNSSEC validation. It=E2=80=99s the only way I know of to v= erify the validity of the RR.

Sent using a machine t= hat autocorrects in interesting ways...

On Aug 15, 2019, at 1:13 PM, Eric Orth <ericorth=3D40goog= le.com@dmarc.ietf.org> wrote:

=EF=BB=BF
On Thu, A= ug 15, 2019 at 12:39 PM John Levine <j= ohnl@taugh.com> wrote:
I also like the paper but it misses the largest concern with
resolverless DNS: it circumvents DNS based access controls.  I realize<= br> this is not a popular position in the IETF, but there are lots of
perfectly good reasons that networks provide filtered DNS.  Even
though it has usually been technically easy to circumvent, most people
don't and it's been good enough.  If it's widely circumvented, we can expect much more intrusive filtering with a lot more collateral damage.
<= /blockquote>

=46rom the Chrome perspective, this is a con= cern I partly share.  I'm mostly ignoring here the circumvention and fo= rced-filtering issues of whether or not the network should be able to mandat= e filtering/manipulation or whether or not clients should be forced to compl= y with such things because that issue is being debated enough over in t= he ADD mailing list.

But if Chrome is using a parti= cular filtering DNS server, especially if that server has been explicitly se= lected by the user or someone with authority over the user's device, seems l= ike it would result in a bad user experience if we then bypassed that filter= ing by retrieving results outside the DNS server.  My initial thinking i= s that we would then ideally only use resolverless DNS if we had knowledge t= hat the in-use recursive resolver is not doing significant filtering.  B= ut such a signal does not currently generally exist, so would we be limited t= o only doing resolverless DNS when the resolver is on a hardcoded list of no= n-filtering resolvers?
--
Resolverless-dns mailing list
Reso= lverless-dns@ietf.org
https://www.ietf.org/mailman/listinfo/= resolverless-dns
= --Apple-Mail-17E27551-4912-4816-BB97-9A4AFDD22795-- From nobody Thu Aug 15 15:11:09 2019 Return-Path: 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 6102E1200C7 for ; Thu, 15 Aug 2019 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 T1WT9LgJLa-m for ; Thu, 15 Aug 2019 15:11:06 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96C41200E7 for ; Thu, 15 Aug 2019 15:11:05 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id j5so2340005ioj.8 for ; Thu, 15 Aug 2019 15:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O2kMbcatKz4ZYBR0qFSdxus4mGHU3e1CNqJ8JvuGYtY=; b=Hzw91mhp+4pgWIv95ft/CXLORK8/dk/ypXgmRFMoO9wwXPnzLMWIp8cZvgow0UmO0O y65eEYlBS36Z92hfG2552yYwHlsSDu81dpe5F99/66ulf9KF/avrsoE6MSLbQKPIt9DL XQ0SiYOxv75PnCAj0eWMdPOlwY4eegZgEToXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=O2kMbcatKz4ZYBR0qFSdxus4mGHU3e1CNqJ8JvuGYtY=; b=Vr3FurA3gPT3LRlPtgFYgIM8fYdTQTnfAlpkKjXP02870Q2Sw5E7+Hf7Goe5kw/XPR TCjzAnEnPooJdGDgcfwslSk4GWGJ31tKOpLLmu3wVLD+zwJQo9lcGQ/K2k3C8ZxcJZk/ B0u/wbz/cmH1DgqjRPDGDFH+wlUZk80mJqF4Pv80LI0Iydbl1Sqp3jiVAq8DgT9XbAlf tS/loL1cbS1/FTrwQkn0pveCeHPLemVd+V4yi4kOlAD0p/UPNFaj3KgFNcyUmIcsZtSe lAuHu29JhHcK46FKdAtFBSmq2m0S4y5Xy/fdFwgPN+AQeXvcnRgEBEc2RLq6QYuwuTrm 6znQ== X-Gm-Message-State: APjAAAVrez3xlRbx+ve1OAxo4BV03F3Z1wcmHy2lmo/V9tnEnT6ESbfg qvhSAmFgAaENYcYm6ioJS7dGMQ== X-Google-Smtp-Source: APXvYqzlE7QRigtKUACVADWyxwgAMzXaCpcaIOTKXFSSmK7fvmkFWpgx6rL+rHGopjMylvgyPVYwwA== X-Received: by 2002:a02:a11e:: with SMTP id f30mr7705468jag.0.1565907064927; Thu, 15 Aug 2019 15:11:04 -0700 (PDT) Received: from [192.168.1.50] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id m10sm3503310ioj.75.2019.08.15.15.11.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 15:11:03 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CD796B7C-AD9B-42C3-BE79-473DDB00D7CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 15 Aug 2019 18:11:02 -0400 In-Reply-To: Cc: Eric Orth , Ben Schwartz , resolverless-dns@ietf.org, John Levine To: Fred Baker References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 22:11:08 -0000 --Apple-Mail=_CD796B7C-AD9B-42C3-BE79-473DDB00D7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 15 Aug 2019, at 18:01, Fred Baker wrote: > One thing I would want to be certain of is that the host did DNSSEC = validation. It=E2=80=99s the only way I know of to verify the validity = of the RR. In the case of a client doing resolverless DNS with a server, presumably = it has already - looked up the name using a resolver - established a TCP connection - completed a TLS handshake with some degree of certificate validation - potentially supplied acceptable credentials for HTTP authentication, = if the server needs them before it is in a position to do name resolution within the resulting = HTTPS bundle. What is the reasoning to require that additional = precautions be taken at this point, compared to the conventional = behaviour where the client continues to get fake results from the cache = of the poisoned resolver? I agree the DNSSEC validation at the client would be nice to see, but I = think that's a more general statement than one that is specific to this = case. Joe --Apple-Mail=_CD796B7C-AD9B-42C3-BE79-473DDB00D7CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXVXYdgAKCRA0jwy9hlI6 LDPHAJ9AF9Rb0/JoOOfsFkQ2Fing3kI3FgCfZgFabv2J+poONY+rD7dE2w6UGOM= =9BUF -----END PGP SIGNATURE----- --Apple-Mail=_CD796B7C-AD9B-42C3-BE79-473DDB00D7CE-- From nobody Thu Aug 15 15:21:44 2019 Return-Path: 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 BB6191200C7 for ; Thu, 15 Aug 2019 15:21:42 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=iXtPurcl; dkim=pass (1536-bit key) header.d=taugh.com header.b=Obifwhsz 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 ZPHyxVUmMaR5 for ; Thu, 15 Aug 2019 15:21:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 274F91200E7 for ; Thu, 15 Aug 2019 15:21:41 -0700 (PDT) Received: (qmail 75322 invoked from network); 15 Aug 2019 22:21:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12638.5d55daf4.k1908; i=johnl-iecc.com@submit.iecc.com; bh=zByuNvnxAmWiPXxS5IikXfsAYyw6Y5GXuvxied6EEII=; b=iXtPurclc0Zm8IPq3x8t+ayBGffMZSvbIKPW8jUNvX7QKxEyf2PIotDz9FReiglwjCZHPLn3lqQBHOBKv/cNSf0EBJF8EtTZglJnv8cpqyJCG7zLi9ErdePn91b1DXWrgKn8KqLd1o+nCRhJveigVEc1lunu6EHNljuyqrqr0GtHHn1KE3Ak3IQ2VfGmja3m+EHK3bRy2ogz9co5EURhmeX6NDHt/nLOi1jWkHuSBmsMTSr0Mb8GjjMv1Whj8nwL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12638.5d55daf4.k1908; olt=johnl-iecc.com@submit.iecc.com; bh=zByuNvnxAmWiPXxS5IikXfsAYyw6Y5GXuvxied6EEII=; b=Obifwhsz/5GWVtpP4k6T+FN+9CTrS6EkUnoeaTZ014+tuqKBeu0G5bKQEQGE8O7VQoS+/Q4Gw3QGyMCama5BaY4rvEfxYFwiDXI4AV5dZniIy+aF14061ZJhPOyTFnqpv7D9gO24iEGmohRfPR+dCKxgeGJ9jnd45gfXu4saUyE18o0XXY1nNigI0BJ5qwZNbRvi26R9RnZvKoFz7JfNxQXZ1/5k2mU6/9waZo2IGqWvtHn4IIDBMIC0v3ly2GB+ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 15 Aug 2019 22:21:39 -0000 Date: 15 Aug 2019 18:21:39 -0400 Message-ID: From: "John R Levine" To: "Eric Orth" Cc: resolverless-dns@ietf.org In-Reply-To: References: <20190815163938.CF9CB85D108@ary.local> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 22:21:43 -0000 On Thu, 15 Aug 2019, Eric Orth wrote: > My initial thinking is that we would then ideally only use > resolverless DNS if we had knowledge that the in-use recursive resolver is > not doing significant filtering. But such a signal does not currently > generally exist, so would we be limited to only doing resolverless DNS when > the resolver is on a hardcoded list of non-filtering resolvers? It's hard to imagine how you could get such a signal in a way that would be useful. Who's going to publish "yeah, sure, bypass me, I don't care"? There are heuristics like looking to see if it's one of the popular n.n.n.n public resolvers, but I wouldn't want to push it too far. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 15 16:07:21 2019 Return-Path: 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 B3D901200EF for ; Thu, 15 Aug 2019 16:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 WnHj-0m4i1jr for ; Thu, 15 Aug 2019 16:07:18 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D5B1200C7 for ; Thu, 15 Aug 2019 16:07:17 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id g67so2580814wme.1 for ; Thu, 15 Aug 2019 16:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ymIPJG+7qKuJGzagr8QLXDqiKgWGeTCkuqNLrVvIr+A=; b=sq6dlbVBETwb2FLGmVSoLmrt1BWCd4fkl1wx54WiHTo3HWcacP0EbgKTgTSsAbeplZ URR3FUHMWcrZE69sSPpW9zTN0Wr5OrrALJFmjojxD4BU8XD58YL/PWiLE8GctapH9bvE CaU0D20MLZKopTt8VhCrzL3O8e/GjfwooWZ7g8bkiUL3a6HiOzomFN0vxWs4NLvDy2gq 6wputLQJet9NTYxg1zuwbvJ8TBCVUOm/DBzpVR8A5jtm2kHYsXLL+AP2HSVh8ksV2pR4 cUxHY6qshGPhpB6LcqREF8kCmpKCVDREdIY8sZFuOJXk0KssVbCL1CK3UqSsqwUO+wbb L3SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ymIPJG+7qKuJGzagr8QLXDqiKgWGeTCkuqNLrVvIr+A=; b=BhV4kvp9cAMSYGS3JBVOnVtkQ1pSqLrv3auvnAByjqVGKKiFxv+6fA0P5jQLgNH6FJ UNHnjZ6UslnvuktLe6ReG1pRG2BBUP8rjfTcMCKcjcHmRCYpdN+rhMQ9x8Px+MguGhq+ s7hIcHy5dhBAYj3ZZjKd8vRPydEr5yNqY+jTPMl3BsC3uFfQpJ8xfQqQkV8Xf80x6vjj KcaYXcoowu/9uTJFWQ/4t87vi0Bm93U4bDnXuuqA/dSMVifV15tw5yNy0ezLL40wmBnX uX2kzfwrxRiq6aBMOcXK4i7XMJ6WBpJvGZJhJLQxjaSCCsUK+Lel3AYQ9ryOqSQHwpPu SGyw== X-Gm-Message-State: APjAAAXD/rgXiIVs25xwnADmiZSrVzRM5N1EcK1cmYCWDM81MAjeYCl4 UuqfPHGsdRZkj+8FldFayKZ6joyPsxQ5Y0SUNpoB7AlO X-Google-Smtp-Source: APXvYqyyXHsQHuUQDl2xoNWs8YeokvMf4xXxRxLfujiEOK/RG8eMYARJu1/KPmUqHwx5G1YjLaV1q7ytIuWN085mcbg= X-Received: by 2002:a1c:d10b:: with SMTP id i11mr4732676wmg.78.1565910435984; Thu, 15 Aug 2019 16:07:15 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> In-Reply-To: From: Eric Orth Date: Thu, 15 Aug 2019 19:07:04 -0400 Message-ID: To: John R Levine Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a1f8705902fef4c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 23:07:20 -0000 --0000000000004a1f8705902fef4c Content-Type: text/plain; charset="UTF-8" On Thu, Aug 15, 2019 at 6:21 PM John R Levine wrote: > It's hard to imagine how you could get such a signal in a way that would > be useful. Who's going to publish "yeah, sure, bypass me, I don't care"? > I imagine most resolvers if they don't do any filtering or other manipulations won't care if they're bypassed by a well-designed resolverless DNS system. The problem is that most of them probably don't care enough to add a signal about it. > > There are heuristics like looking to see if it's one of the popular > n.n.n.n public resolvers, but I wouldn't want to push it too far. > Essentially the "hardcoded list of non-filtering resolvers" I mentioned. Maybe such methods are enough to get reasonable use of resolverless-DNS, but I hope somebody can think of a way to do better. --0000000000004a1f8705902fef4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2019 at 6:21 PM John R Le= vine <johnl@taugh.com> wrote:<= br>
It's hard to imagine how you could get such a signal in a way that woul= d
be useful.=C2=A0 Who's going to publish "yeah, sure, bypass me, I = don't care"?

I imagine most re= solvers if they don't do any filtering or other manipulations won't= care if they're bypassed by a well-designed resolverless DNS system.= =C2=A0 The problem is that most of them probably don't care enough to a= dd a signal about it.
=C2=A0

There are heuristics like looking to see if it's one of the popular n.n.n.n public resolvers, but I wouldn't want to push it too far.

Essentially the "hardcoded list of non-= filtering resolvers" I mentioned.=C2=A0 Maybe such methods are enough = to get reasonable use of resolverless-DNS, but I hope somebody can think of= a way to do better.
--0000000000004a1f8705902fef4c-- From nobody Thu Aug 15 20:53:46 2019 Return-Path: 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 70660120013 for ; Thu, 15 Aug 2019 20:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MsKcXAgI; dkim=pass (1536-bit key) header.d=taugh.com header.b=eoUSGw6t 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 Ol8pfqbnURN8 for ; Thu, 15 Aug 2019 20:53:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 C89AD12003E for ; Thu, 15 Aug 2019 20:53:41 -0700 (PDT) Received: (qmail 80788 invoked from network); 16 Aug 2019 03:53:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13b91.5d5628c3.k1908; i=printer-iecc.com@submit.iecc.com; bh=Sm+fNficuI2pa+4XBoHgIzi4+aZn+9CpYUvDC9VdqiI=; b=MsKcXAgIFN2T4Rh12ISqjoKiVQ218UlaKpDfKkKlxxLCtFSsEFXx2Hp6o/iE7bWDYb3twGVivtAPfoc9qNi5rHNTo0cmzETJCK4lM5QPVmaMqENeR+uxgFWuKxW9q/RJvi0Ymw6BRak/ROUHvGDPihjcHrgLefNdTpUgb5yb+kGfg43hj3TRztzBfEGdh8Lhtl3tHiyscXT19B4uhfGgOl5dGuwwOc/k7myQvREwBLsFsY6wL5aSp6cxr6lYvgko DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13b91.5d5628c3.k1908; olt=printer-iecc.com@submit.iecc.com; bh=Sm+fNficuI2pa+4XBoHgIzi4+aZn+9CpYUvDC9VdqiI=; b=eoUSGw6tey4uWLMBCqZT2CjUKFOcS75ICCp+J9hftREzB7Jfy7XuAN2MfjdWdQavb+ZdF6itFxziXr8bseH8lbFGQuMKykQNPUYAgfXn9MB2GUdtaqLkVZIwUONMOO+6q5GPyoNsEphg+qeY6jqyL2mfNv+quImfUSJXp4az++7TAgdlLZLDoCpKoUBXGus9F74fL07rE7pDH3DWXqrRiYVw5K3ci84bjcN/hmG0QsGUZ9TYYhib1s5XncnGD7uG Received: from ary.local ([73.33.141.87]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 16 Aug 2019 03:53:38 -0000 Received: by ary.local (Postfix, from userid 501) id 6E1E4864958; Thu, 15 Aug 2019 23:53:37 -0400 (EDT) Date: 15 Aug 2019 23:53:37 -0400 Message-Id: <20190816035338.6E1E4864958@ary.local> From: "John Levine" To: resolverless-dns@ietf.org Cc: sy@informatik.uni-hamburg.de In-Reply-To: <8a8754b1-c646-34fc-a13b-d69757b807f3@informatik.uni-hamburg.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 03:53:44 -0000 In article <8a8754b1-c646-34fc-a13b-d69757b807f3@informatik.uni-hamburg.de> you write: >-=-=-=-=-=- > >Hi John, > >On 8/15/19 18:39, John Levine wrote: >> >> I also like the paper but it misses the largest concern with >> resolverless DNS: it circumvents DNS based access controls. > >Resolver-less DNS does not circumvent DNS-based access controls. First, >clients can configure their user agent to filter the DNS records >retrieved via resolver-less DNS to enforce such access controls. This strikes me as rather overoptimistic. Sure, a sophisticated user can set up her DNS configuration do all sorts of stuff. But until now, the other 99.99% of normal users just use whatever DNS configuration their system gives them. They don't know what DNS is, and if a browser or other application does resolverless DNS, they don't understand the implications or how to turn it off. If the browser pops up a permission window, it says: blah blah security parp parp DNS bloop bloop extremely dangerous gargle gargle safety? so they'll click OK to make it go away. R's, John From nobody Fri Aug 16 00:27:57 2019 Return-Path: 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 63458120837 for ; Fri, 16 Aug 2019 00:27:48 -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 qMf9WYptzIIl for ; Fri, 16 Aug 2019 00:27:45 -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 27A5B12083D for ; Fri, 16 Aug 2019 00:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 2264C91A for ; Fri, 16 Aug 2019 09:27:43 +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 8GwKARWUo2zG for ; Fri, 16 Aug 2019 09:27:42 +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 021E1919 for ; Fri, 16 Aug 2019 09:27:41 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190815163938.CF9CB85D108@ary.local> From: Erik Sy 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: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> Date: Fri, 16 Aug 2019 09:27:40 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010003040006090309070904" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:27:55 -0000 This is a cryptographically signed message in MIME format. --------------ms010003040006090309070904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Ted, On 8/15/19 23:03, Ted Hardie wrote: > > Agreed, but your proposal appears as written to allow any web server > to try the attack, where it was formerly limited to a configured > resolver.=C2=A0 Unless I misunderstand the proposal, that a significant= > change in attack surface. Ok, we can include this into the privacy discussion of resolver-less DNS. In detail, an adversary providing tampered DNS records for a specific hostname can possibly learn that the user agent had established a connection to this hostname in the past. A successful attack requires the user agent to posses valid state of that prior connection allowing an abbreviated connection establishment such as QUIC source address tokens or TLS session resumption tickets. > =C2=A0 > =C2=A0It also raises the risk that a client will receive a server > authentication from a CA not intended by the domain owner (our friend > the enterprise, an attacker, a government, etc.).=C2=A0 We have some > mitigations for that, but they are not complete. The problem you are describing is not introduced by resolver-less DNS. The fact that the client may receive a server authentication from a CA not intended by the domain owner applies also to the traditional DNS. As mentioned earlier, I think attacks assuming a broken PKI cannot be effectively mitigated by DNS. Erik > > Unless you somehow limit the number of domains a web server can > provide DNS records for in some way that approximately matches their > own URL authority, this seems fairly risky to me.=C2=A0=C2=A0 You can e= liminate > the risk for a DNSSEC validating application if the DNS records allow > the validation to occur.=C2=A0=C2=A0 But that is not, at least yet, com= mon. > > regards, > > Ted > > > Thus, I do not understand why an > interdependence with the ticket lifetime is created. > > > > =C2=A0 > > > Erik=C2=A0 > > > =C2=A0 RFC 5077 says this: > >=C2=A0 =C2=A0 A client SHOULD delete the ticket and associated sta= te when > the time expires. > >=C2=A0 =C2=A0 It MAY delete the ticket earlier based on local poli= cy.=C2=A0 A > server MAY > >=C2=A0 =C2=A0 treat a ticket as valid for a shorter or longer peri= od of > time than > >=C2=A0 =C2=A0 what is stated in the ticket_lifetime_hint. > > If you know a server sets 0 or a long lifetime, in other words, y= ou > > may be able to guess that a session ticket is available, but > otherwise > > it is a crapshoot either for the benign DNS-record supplying host= or > > an attacker.=C2=A0 > > > > Given the large number of cases that will have to follow > fallback DNS > > lookup for the authentication, I think this a useful building blo= ck > > only for very popular services (since they are likely to be in th= e > > cache).=C2=A0 Given the other resources they have and the > reputational risk > > of allowing random sites to provide DNS records related to them, = I'm > > not yet sure that this is worth it. > > > > Ted > > > > *Imagine you are a government which wishes to detect when > citizens use > > GRINDR, as you disapprove of same sex encounters.=C2=A0 You can h= ave > > government=C2=A0 and affiliated sites push GRINDR DNS records usi= ng this > > method; when someone with a fresh TLS ticket for GRINDR tries to > > connect, you get their IP address and whatever other data leaked = in > > the exchange.=C2=A0 You can limit this risk in various ways (e.g.= by > > requiring the presented TLS certificate of the DNS-record supplyi= ng > > host have the domain in its list of alternative names), but this > > limits the effectiveness of this method and also runs the risk th= at > > governments may have root certificates that can generate those. > > > > > > > > --=20 > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > > --------------ms010003040006090309070904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYwNzI3NDBaMC8GCSqGSIb3DQEJBDEiBCAG00CGiJX1 KViWyGDoaywNFVfTV5d8IOxQD2MTUtYeWTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQB2YxsoA3lQ0hr7cPBVOrzD0unrXZgge1V77zer 7GWl0iZfqVw3fQZul3vAijKeIOVmQ1K8f/rYdNQtQh/e2Equ51tccsxDxIzz9YGVM4EOEaLc dwierVuy0eC9eCypZXwO8mrqXlBuiRonB3Aeh9tppq+OylHhs5/9LiSf+t2HPP61oJovtZ5E LnujpsgCmXJgVrQRFyuoPOZDoJDxiqFam6FXopvV3S04b67v/7DU2GK8TQCsFqhI5nHSG9Av IJKsD5ymWwD2O8ZDjlKeOG5xKdm1wm9S9KPeQiBn/vHmttTfAEp3FW3QkJghAivl+xuPIGS7 69kK9vyv1PE5yztlAAAAAAAA --------------ms010003040006090309070904-- From nobody Fri Aug 16 05:46:38 2019 Return-Path: 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 AD5C712011A for ; Fri, 16 Aug 2019 05:46:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 5u_-80HqefsT for ; Fri, 16 Aug 2019 05:46:35 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0501200A1 for ; Fri, 16 Aug 2019 05:46:35 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 125so4561237qkl.6 for ; Fri, 16 Aug 2019 05:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=xVypZpiuZlGx7g3EplB0yor4kNySFEnQmpKVxPCEsE8=; b=pIN3IlDYajjjriQzYIHI1tdqXQQoVY1x5tbt5HUQHFNCdrVlp4Gp4Arsyzvy1Hh8kq Bo8dZrN2fKYRYC6PDqFjNiLXOLJjYEsh4PGfd2gVwjj1mlymdewRWpUwTpZGvKfIu0ez mEkkkVjgy4M9dmGNowQjyoRGmbubouLIpGR305brKBmrICPoHpuNyhVuWC/HELuIrOgP YUCq8Jic0Vqh5mQI3RaxNxsWjKNi6NUZov3eOe16NiMaVowEfKNX2bxDv9pPgNMfN6cx RLqwA4hwkvTSfnBTKDRjBulsdVxRTnZYURBSo65c3Sllo1VKTuJMNZIPHbPNDnTbH2T/ IUEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=xVypZpiuZlGx7g3EplB0yor4kNySFEnQmpKVxPCEsE8=; b=OTqa+r+Z4ULWHIsl6Yj1c0xmEUgu3PfzQkR6bGrIWpcW1FfnxQNFRW4QsNHei8Fnlc 8LPIdd2WCAho7LA16LON+L5KRUZZbk2n9BXXr9XcBp8XTgu3a0cgO6H9j4h9w79Y7xa6 xTrbDrSkzv96ZQ8sE3wE/TC6uAcocM/ukqPtOLLAjNqWqihfTgjoFABoEQzuq1A084rX yMRxx01/rgqdc4vLwMDJv4eJLtDB7PJJ6X5JDDsnO5XN13qrPX9pJwO417VgpGBUDIve grXopPrmASQYpIOsxRjFpJoaqBuNLvHP9wh7f+fOv73GxoNk6PKa2GhYFIyKpUwlJhRW lLlA== X-Gm-Message-State: APjAAAWoqh/5JUJAxS8Vw4Vw9OuhilFvL8QgJ7cynTnNXlCvTmW8odbG 808OV8UpkwZTFrg9n1HAEb7zTuAF26ucpg== X-Google-Smtp-Source: APXvYqz0R3dciEIH3gf6HTYmEJuXLeaR1Ztvrh3o/NH284lM+GtmEdbi250pyMytjbYy0SU3E8ARDw== X-Received: by 2002:ae9:e8d3:: with SMTP id a202mr8386222qkg.256.1565959593951; Fri, 16 Aug 2019 05:46:33 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id d22sm2775064qto.45.2019.08.16.05.46.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2019 05:46:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 16 Aug 2019 08:46:32 -0400 Message-Id: References: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> Cc: resolverless-dns@ietf.org In-Reply-To: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: iPhone Mail (17A568) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 12:46:37 -0000 On Aug 16, 2019, at 03:28, Erik Sy wrote: >=20 > I think attacks assuming a broken PKI cannot be > effectively mitigated by DNS. DNSSEC +TLSA doesn=E2=80=99t work?= From nobody Fri Aug 16 06:36:13 2019 Return-Path: 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 9056C120133 for ; Fri, 16 Aug 2019 06:36:11 -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 OnVWriIWrOLf for ; Fri, 16 Aug 2019 06:36:08 -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 4FC1A120048 for ; Fri, 16 Aug 2019 06:36:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id CA311578; Fri, 16 Aug 2019 15:36:05 +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 OV8GYeol9VXQ; Fri, 16 Aug 2019 15:36:05 +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 C571C577; Fri, 16 Aug 2019 15:36:04 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Ted Lemon Cc: resolverless-dns@ietf.org References: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> From: Erik Sy 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: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> Date: Fri, 16 Aug 2019 15:36:03 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080900090306020009050505" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 13:36:12 -0000 This is a cryptographically signed message in MIME format. --------------ms080900090306020009050505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/16/19 14:46, Ted Lemon wrote: > On Aug 16, 2019, at 03:28, Erik Sy wrote= : >> I think attacks assuming a broken PKI cannot be >> effectively mitigated by DNS. > DNSSEC +TLSA doesn=E2=80=99t work? Looking at the deployment issues of DNSSEC [1] and TLSA [2], I think DNSSEC+TLSA do not solve the broken PKI problem on the web. Furthermore, I'm not aware of any user agent enforcing a strict validation of DNSSEC+TLSA, which would be necessary to mitigate the described attacks. 1: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-chu= ng.pdf 2: https://link.springer.com/chapter/10.1007/978-3-319-17172-2_15 --------------ms080900090306020009050505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYxMzM2MDNaMC8GCSqGSIb3DQEJBDEiBCAzXYjEhtyn QDlGCVg6ggWRz4a1sDiHbaySHklHeuIRTjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAlXd5OtiFIKRwF8oaxnl+NPEybOsf2cJdthJuI dlcNrwT4SAwQYeBsBJiZ4Da7EQ9kaCWErwqtsj8h5sfsl+IrcZdFnCoIiAdpEOP6Ew9k80kH 3/itBY7IOxxZIEM+EFj24s4nPZcbOVM1BftoP1+Mj1huN3b7mRCeUEkptGN7tbDzBk1VNgMs 7cJYKbXLgAR9kQ7jHmKl974Mjs3HNHmoVSSSVsZpp95fq1blUcmsyMQMmmPzNppyAyx5HVw8 JF+DmAn+HUTFIhhL0VGfBx8xHMMRIVeHuVYuLkjkzcxW52NWkdbatgLNhXRQPg8JRNy5pBlw fFelt1M++ZKNnM7kAAAAAAAA --------------ms080900090306020009050505-- From nobody Fri Aug 16 07:39:59 2019 Return-Path: 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 40462120825 for ; Fri, 16 Aug 2019 07:39:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 7Quj8M4HzaJl for ; Fri, 16 Aug 2019 07:39:55 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599EC120819 for ; Fri, 16 Aug 2019 07:39:55 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id s14so4944241qkm.4 for ; Fri, 16 Aug 2019 07:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ZC6e/7e2hgGiRK0wAmRIzMy4jQq9eUR6CBmLba95NXE=; b=imLzqudSjEolpSRaBos9Ejm4RhhX/QqRD2THXMyqXIgWy/J9/0Z8+JyI9RuBs07mm0 g9sPRPiwajZnkKSRYX5ywsEpiiN5tBe4vgOGYIrXLPlWxYEsWZ3RqT0zX+rD64FEVX3R GdeGAkfBCA48wDypbiL5g2sa4+U2Pyf4XSA58js9NoKpWbWYtIuChZWOs/ek60l7W6SP GxwOr7n5+ja7uSpiE/Ud6ASXcrEsP9LeExbq8n/p1cN+DdTZC0Ezd6Vj4vHX2eS6g3lH AJGjgjnil6jUDQxDfjDiNBTqkZvhMeN/vh4r30cUvKyFmkHol52BzMIHUanQc4XdR4u8 KsFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ZC6e/7e2hgGiRK0wAmRIzMy4jQq9eUR6CBmLba95NXE=; b=kn4XbE5vCGLB419O51trfXo/l9oCLQ8ZKcCflIn9ve8SjtRZjIv3HlFgRBthi81aFp PySjxRa4yEr5YpMov/UdHqgzQ1Gi2Z2VkbSb9RBacsIJWIO4YXmku+n6VpC4zioKPq5l yqzadnAM12I/ZBCdzg7GGmhd9HsPlJazBGia0Ylv9pf7/LQqI61ub/7Oo0ZuPx67N+C5 IEjQmAl6wxm18J0gX70GdL5LVyyFHr66e3sHHhzJAnc0BtExURGXI4NAzo+unT3lwdUT UcU1DNHK1b/2YmcoYyy7rXqw0JqlPcZVaFDVkqi0qnTaV4gL1okDvHYN936hdrZPFZDS tKqA== X-Gm-Message-State: APjAAAU0Ofexw3pbPhs9NUQTSX/IXQvsJ9i1Ywxuu9a7IByaASocKI5B hJkAut67j/Lzk2gpqiVWb/tt5uSp5YEdgA== X-Google-Smtp-Source: APXvYqwPC3NREJ7+hkPCfLeYBB3eWKsVbV2sh70B/JdjvNsfi5gNCQk4MnMXI7+Gn635tznN7rzshw== X-Received: by 2002:a37:2c41:: with SMTP id s62mr9394055qkh.415.1565966394338; Fri, 16 Aug 2019 07:39:54 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id k74sm3224277qke.53.2019.08.16.07.39.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2019 07:39:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 16 Aug 2019 10:39:52 -0400 Message-Id: <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com> References: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> Cc: resolverless-dns@ietf.org In-Reply-To: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: iPhone Mail (17A568) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 14:39:57 -0000 Both of those papers talk about incompetence of operation, not about technic= al weaknesses. Competently operated DNSSEC will not have the problems these t= wo papers describe. Are you aware of any technical problem with using TLSA t= o prevent PKI attacks, or is this just FUD? Sent from my iPhone > On Aug 16, 2019, at 09:36, Erik Sy wrote: >=20 > =EF=BB=BF >> On 8/16/19 14:46, Ted Lemon wrote: >>> On Aug 16, 2019, at 03:28, Erik Sy wrote:= >>> I think attacks assuming a broken PKI cannot be >>> effectively mitigated by DNS. >> DNSSEC +TLSA doesn=E2=80=99t work? > Looking at the deployment issues of DNSSEC [1] and TLSA [2], I think > DNSSEC+TLSA do not solve the broken PKI problem on the web. Furthermore, > I'm not aware of any user agent enforcing a strict validation of > DNSSEC+TLSA, which would be necessary to mitigate the described attacks. >=20 > 1: > https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-chun= g.pdf >=20 > 2: https://link.springer.com/chapter/10.1007/978-3-319-17172-2_15 >=20 From nobody Fri Aug 16 08:26:01 2019 Return-Path: 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 371B512081D for ; Fri, 16 Aug 2019 08:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Xk8RzEU-drTp for ; Fri, 16 Aug 2019 08:25:36 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 76D6C120846 for ; Fri, 16 Aug 2019 08:25:36 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id 9F2D216054; Fri, 16 Aug 2019 17:25:34 +0200 (CEST) Date: Fri, 16 Aug 2019 17:25:32 +0200 From: Steffen Nurpmeso To: Ted Lemon Cc: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org, Steffen Nurpmeso Message-ID: <20190816152532.z1q1S%steffen@sdaoden.eu> In-Reply-To: <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com> References: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com> Mail-Followup-To: Ted Lemon , sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.14-31-g02ec9e48 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:25:53 -0000 Ted Lemon wrote in <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com>: |Both of those papers talk about incompetence of operation, not about \ |technical weaknesses. Competently operated DNSSEC will not have the \ |problems these two papers describe. Are you aware of any technical \ |problem with using TLSA to prevent PKI attacks, or is this just FUD? Competence does not help if governments or companies enforce some policy. If they are willing to channel data and require installation of a certificate in your CA pool, then the best you can get is increased effort on their side, by introducing a shadow DNS topology, unless i am mistaken. I do not understand, and never (~18 years) did, why the complexity of DNS is increased so much; instead of moving over to secure transport that is. And if you want to sign data bundles, then those keys could also be used, they have the potential for it, do they. Repeatedly connect up to the root domain of your URL in question, and collect certificates along the way, unless you have the complete chain, which you can cache locally. Especially if you now even pump the data as such over an already open HTTP channel. But in general this looked to me the much more elegant resolution (once i looked at DNSSEC and TSIG and said "no (hopefully not)"). And much easier to implement, and by using facilities of libraries which see many eyes. And keeping the core protocol clean. What do you win more than (possibly) increased complexity on the door through the wall? But "leaving lonely people fight in dark side streets as opposed to perceptable noise when someone enforces entries in local CA pools"? Just my one cent. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Aug 16 08:35:51 2019 Return-Path: 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 C5471120824 for ; Fri, 16 Aug 2019 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 PS8A1G4VI8Oz for ; Fri, 16 Aug 2019 08:35:48 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860E212080A for ; Fri, 16 Aug 2019 08:35:48 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 52B03892E8 for ; Fri, 16 Aug 2019 15:35:48 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Date: Fri, 16 Aug 2019 15:35:47 +0000 Message-ID: <22057767.kxZJMFVDak@linux-9daj> Organization: none In-Reply-To: <20190816152532.z1q1S%steffen@sdaoden.eu> References: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com> <20190816152532.z1q1S%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:35:50 -0000 On Friday, 16 August 2019 15:25:32 UTC Steffen Nurpmeso wrote: > ... > > I do not understand, and never (~18 years) did, why the complexity > of DNS is increased so much; instead of moving over to secure > transport that is. DNS over TLS (note, this is not the same as DNS over HTTPS) is such a transport. however, transport security doesn't assure data authenticity. therefore the another complexity (DNSSEC) was added first. and, neither of these protocols can be used to express permission, so another complexity (TSIG) was added before either of the others. > And if you want to sign data bundles, then > those keys could also be used, they have the potential for it, do > they. no. both for reasons of caching and reasons of policy and monitoring, most DNS transactions are bounced through relays called "full resolvers". if you try to design these out, your system will lose vital properties compared to DNS itself. > Repeatedly connect up to the root domain of your URL in > question, and collect certificates along the way, unless you have > the complete chain, which you can cache locally. Especially if > you now even pump the data as such over an already open HTTP > channel. But in general this looked to me the much more elegant > resolution (once i looked at DNSSEC and TSIG and said "no > (hopefully not)"). And much easier to implement, and by using > facilities of libraries which see many eyes. And keeping the core > protocol clean. the losses from this approach would be, as stated above, vital. the web isn't by far the only app running on the internet, and while it will grow, the internet is larger will grow faster. -- Paul From nobody Fri Aug 16 08:51:14 2019 Return-Path: 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 1B184120824 for ; Fri, 16 Aug 2019 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.com 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 rgBUeKWRutPq for ; Fri, 16 Aug 2019 08:51:09 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F42912029C for ; Fri, 16 Aug 2019 08:51:09 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j5so7105298ioj.8 for ; Fri, 16 Aug 2019 08:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GX08mOwtrfEyzcHOsEOsOv2bDBnnmbFS+LDZhhX2Kq4=; b=tUOQiatE/HUb5xzqCY1vQWfKMOIcX1hq1g9sIOWL3VXy4SfBYYGZdQG5IpXctEq9PW XGQhV1fbx4OJE/irVjalSPW0qQWJAEgS9kPkSDmiAV7RqJLWS4ycG34JeEnucqWXqAvU PojW/azHgcIsEcFIehlnzPr+I/HHozeVrSh1QOOBoOPuITT4jc8CPEuzO5MirP6kOxap DY1RHC9V+v+FLDC74AcqjZHqidVKSltXPebhLxqtucRG+Lu5fMSoc+vKsHKZxSYxnozb RDsc76LfcsWPECj1ykYNm2RYW5bS+gg+8m/W/hxQtwMdUW+GY9p8yLy3q23G7nGhWwdF YtpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GX08mOwtrfEyzcHOsEOsOv2bDBnnmbFS+LDZhhX2Kq4=; b=abZFgnzvVQDfNWfV+zDD4ThSesitooGObm7c1cGF5EFB+8AQ+uddsk+/PAAqIJeFqZ m2ZPoSIiH777ruZS9vkjxZIbIRteMsR3Q68NtoFCYGeuYX/czTAdaP66x6S+E07I4r8T hg0tYALzQn1rPankiYIcaCKQQhvsRfQrbtHLJ8Pgcpfg/lgY+rboIZ5xMag/1u5bgVfu Jjg+ctMkCMU/1cMAtWH4FS5QOy4LQbf9PH9Upke3bCl+yMrLr6fm5Ds4NatEXyZQrWIJ U3RvmeQzifHhTcd9aSz4nzIphbR3NONCKcbs9msTrA2fK5JnyXqVMFNwZTs2Wi3Qx6oW 23Zg== X-Gm-Message-State: APjAAAW7DgNZr0XBfDnNVv8zoFXG8FlYG/OrPItOnxToFz95Edma4lr1 b4+5raE0CD/1JAWFswnCQDU3LLLBNHRCuB6UOoU= X-Google-Smtp-Source: APXvYqzhmlFERBR9foPoPcR0u5otsPpMiR57RQmS41qhvvu/hwgHAw/jHuSwvcS7+8yJ8hTsssvBreRvQY/XpwRMhUM= X-Received: by 2002:a6b:720e:: with SMTP id n14mr12311409ioc.139.1565970668007; Fri, 16 Aug 2019 08:51:08 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> In-Reply-To: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> From: Ted Hardie Date: Fri, 16 Aug 2019 08:50:41 -0700 Message-ID: To: sy@informatik.uni-hamburg.de Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="00000000000065356305903df5d1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:51:12 -0000 --00000000000065356305903df5d1 Content-Type: text/plain; charset="UTF-8" Howdy, On Fri, Aug 16, 2019 at 12:28 AM Erik Sy wrote: > Hi Ted, > > On 8/15/19 23:03, Ted Hardie wrote: > > > > Agreed, but your proposal appears as written to allow any web server > > to try the attack, where it was formerly limited to a configured > > resolver. Unless I misunderstand the proposal, that a significant > > change in attack surface. > Ok, we can include this into the privacy discussion of resolver-less > DNS. In detail, an adversary providing tampered DNS records for a > specific hostname can possibly learn that the user agent had established > a connection to this hostname in the past. A successful attack requires > the user agent to posses valid state of that prior connection allowing > an abbreviated connection establishment such as QUIC source address > tokens or TLS session resumption tickets. > Yes, this is true, but I thought you asserted that it would opportunistically attempt to use the provided records. That means it could also leak the interest of the client in a specific resource to a potentially malign collector at the instigation of any web site providing the malign DNS record; that's the increase in attack surface for the existing attack. At the very least, that appears to require clients to cache where DNS records came from in their cache, so that they can build a reputation for sources that supplied bad data and ignore data from sources that gave bad data. That's a far from perfect mitigation, of course, but it helps some. > > > > It also raises the risk that a client will receive a server > > authentication from a CA not intended by the domain owner (our friend > > the enterprise, an attacker, a government, etc.). We have some > > mitigations for that, but they are not complete. > > The problem you are describing is not introduced by resolver-less DNS. > Agreed, but it also can't be ignored that the new source of supplied DNS records gives a new opportunity to line up the facilities needed for a successful attack. regards, Ted > The fact that the client may receive a server authentication from a CA > not intended by the domain owner applies also to the traditional DNS. As > mentioned earlier, I think attacks assuming a broken PKI cannot be > effectively mitigated by DNS. > > Erik > > > > > Unless you somehow limit the number of domains a web server can > > provide DNS records for in some way that approximately matches their > > own URL authority, this seems fairly risky to me. You can eliminate > > the risk for a DNSSEC validating application if the DNS records allow > > the validation to occur. But that is not, at least yet, common. > > > > regards, > > > > Ted > > > > > > Thus, I do not understand why an > > interdependence with the ticket lifetime is created. > > > > > > > > > > > > > > Erik > > > > > RFC 5077 says this: > > > A client SHOULD delete the ticket and associated state when > > the time expires. > > > It MAY delete the ticket earlier based on local policy. A > > server MAY > > > treat a ticket as valid for a shorter or longer period of > > time than > > > what is stated in the ticket_lifetime_hint. > > > If you know a server sets 0 or a long lifetime, in other words, you > > > may be able to guess that a session ticket is available, but > > otherwise > > > it is a crapshoot either for the benign DNS-record supplying host > or > > > an attacker. > > > > > > Given the large number of cases that will have to follow > > fallback DNS > > > lookup for the authentication, I think this a useful building block > > > only for very popular services (since they are likely to be in the > > > cache). Given the other resources they have and the > > reputational risk > > > of allowing random sites to provide DNS records related to them, > I'm > > > not yet sure that this is worth it. > > > > > > Ted > > > > > > *Imagine you are a government which wishes to detect when > > citizens use > > > GRINDR, as you disapprove of same sex encounters. You can have > > > government and affiliated sites push GRINDR DNS records using this > > > method; when someone with a fresh TLS ticket for GRINDR tries to > > > connect, you get their IP address and whatever other data leaked in > > > the exchange. You can limit this risk in various ways (e.g. by > > > requiring the presented TLS certificate of the DNS-record supplying > > > host have the domain in its list of alternative names), but this > > > limits the effectiveness of this method and also runs the risk that > > > governments may have root certificates that can generate those. > > > > > > > > > > > > > > -- > > Resolverless-dns mailing list > > Resolverless-dns@ietf.org > > https://www.ietf.org/mailman/listinfo/resolverless-dns > > > > > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --00000000000065356305903df5d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Fri, Aug 16, 2019 at 12:28 AM Erik Sy <sy@informatik.uni-hamburg.de> wrote:
<= /div>
Hi Ted,

On 8/15/19 23:03, Ted Hardie wrote:
>
> Agreed, but your proposal appears as written to allow any web server > to try the attack, where it was formerly limited to a configured
> resolver.=C2=A0 Unless I misunderstand the proposal, that a significan= t
> change in attack surface.
Ok, we can include this into the privacy discussion of resolver-less
DNS. In detail, an adversary providing tampered DNS records for a
specific hostname can possibly learn that the user agent had established a connection to this hostname in the past. A successful attack requires
the user agent to posses valid state of that prior connection allowing
an abbreviated connection establishment such as QUIC source address
tokens or TLS session resumption tickets.
=C2=A0
=
Yes, this is true, but I thought you asserted that it would opportunis= tically attempt to use the provided records.=C2=A0 That means it could also= leak the interest of the client in a specific resource to a potentially ma= lign collector at the instigation of any web site providing the malign DNS = record; that's the increase in attack surface for the existing attack.= =C2=A0 At the very least, that appears to require clients to cache where DN= S records came from in their cache, so that they can build a reputation for= sources that supplied bad data and ignore data from sources that gave bad = data.=C2=A0 That's a far from perfect mitigation, of course, but it hel= ps some.
=C2=A0
> =C2=A0
> =C2=A0It also raises the risk that a client will receive a server
> authentication from a CA not intended by the domain owner (our friend<= br> > the enterprise, an attacker, a government, etc.).=C2=A0 We have some > mitigations for that, but they are not complete.

The problem you are describing is not introduced by resolver-less DNS.
<= /blockquote>

Agreed, but it also can't be ignored th= at the new source of supplied DNS records gives a new opportunity to line u= p the facilities needed for a successful attack.

r= egards,

Ted
=C2=A0
The fact that the client may receive a server authentication from a CA
not intended by the domain owner applies also to the traditional DNS. As mentioned earlier, I think attacks assuming a broken PKI cannot be
effectively mitigated by DNS.

Erik

>
> Unless you somehow limit the number of domains a web server can
> provide DNS records for in some way that approximately matches their > own URL authority, this seems fairly risky to me.=C2=A0=C2=A0 You can = eliminate
> the risk for a DNSSEC validating application if the DNS records allow<= br> > the validation to occur.=C2=A0=C2=A0 But that is not, at least yet, co= mmon.
>
> regards,
>
> Ted
>
>
>=C2=A0 =C2=A0 =C2=A0Thus, I do not understand why an
>=C2=A0 =C2=A0 =C2=A0interdependence with the ticket lifetime is created= .
>
>
>
> =C2=A0
>
>
>=C2=A0 =C2=A0 =C2=A0Erik=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0> =C2=A0 RFC 5077 says this:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 A client SHOULD delete the ticket= and associated state when
>=C2=A0 =C2=A0 =C2=A0the time expires.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 It MAY delete the ticket earlier = based on local policy.=C2=A0 A
>=C2=A0 =C2=A0 =C2=A0server MAY
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 treat a ticket as valid for a sho= rter or longer period of
>=C2=A0 =C2=A0 =C2=A0time than
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 what is stated in the ticket_life= time_hint.
>=C2=A0 =C2=A0 =C2=A0> If you know a server sets 0 or a long lifetime= , in other words, you
>=C2=A0 =C2=A0 =C2=A0> may be able to guess that a session ticket is = available, but
>=C2=A0 =C2=A0 =C2=A0otherwise
>=C2=A0 =C2=A0 =C2=A0> it is a crapshoot either for the benign DNS-re= cord supplying host or
>=C2=A0 =C2=A0 =C2=A0> an attacker.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Given the large number of cases that will have= to follow
>=C2=A0 =C2=A0 =C2=A0fallback DNS
>=C2=A0 =C2=A0 =C2=A0> lookup for the authentication, I think this a = useful building block
>=C2=A0 =C2=A0 =C2=A0> only for very popular services (since they are= likely to be in the
>=C2=A0 =C2=A0 =C2=A0> cache).=C2=A0 Given the other resources they h= ave and the
>=C2=A0 =C2=A0 =C2=A0reputational risk
>=C2=A0 =C2=A0 =C2=A0> of allowing random sites to provide DNS record= s related to them, I'm
>=C2=A0 =C2=A0 =C2=A0> not yet sure that this is worth it.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Ted
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> *Imagine you are a government which wishes to = detect when
>=C2=A0 =C2=A0 =C2=A0citizens use
>=C2=A0 =C2=A0 =C2=A0> GRINDR, as you disapprove of same sex encounte= rs.=C2=A0 You can have
>=C2=A0 =C2=A0 =C2=A0> government=C2=A0 and affiliated sites push GRI= NDR DNS records using this
>=C2=A0 =C2=A0 =C2=A0> method; when someone with a fresh TLS ticket f= or GRINDR tries to
>=C2=A0 =C2=A0 =C2=A0> connect, you get their IP address and whatever= other data leaked in
>=C2=A0 =C2=A0 =C2=A0> the exchange.=C2=A0 You can limit this risk in= various ways (e.g. by
>=C2=A0 =C2=A0 =C2=A0> requiring the presented TLS certificate of the= DNS-record supplying
>=C2=A0 =C2=A0 =C2=A0> host have the domain in its list of alternativ= e names), but this
>=C2=A0 =C2=A0 =C2=A0> limits the effectiveness of this method and al= so runs the risk that
>=C2=A0 =C2=A0 =C2=A0> governments may have root certificates that ca= n generate those.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Resolverless-dns mailing list
>=C2=A0 =C2=A0 =C2=A0Resolverless-dns@ietf.org <mailto:Resolverless-dns@ietf.org><= br> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/m= ailman/listinfo/resolverless-dns
>
>

--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--00000000000065356305903df5d1-- From nobody Fri Aug 16 08:54:16 2019 Return-Path: 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 282E71207FC for ; Fri, 16 Aug 2019 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 Ya6HuB21aW3y for ; Fri, 16 Aug 2019 08:54:12 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6383312029C for ; Fri, 16 Aug 2019 08:54:12 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g17so5072613qkk.8 for ; Fri, 16 Aug 2019 08:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mldCPyapcgn9G947hVwaIJyQ45F+5eXGhK+el1tvLJ8=; b=mlOZPOtJLw6RVjN8us0kOw2022tCeTdaTQjXTKC0+t9fOoG2DdcT8gUpmrUaz18pSJ s8C/kQiC235yBZ0ox4nOSaaSdYAD29N4gcDDqVFMWEm5dWCGZP2XE+x0j1eUCpFa+U3F Pmz7RNTJZvJjnPwT1ilk0LTyac3M130RoZm5SBXwdxt/Jd9O0lIaI2awDZlsaSa51dIW sVbF8nhNaBxto59pIBDHJBOG4uiWwrp2+EB7EdFSMZFemY6gP6sbDtzdAT1Cjw/fqkHN SqmJUt6V+IhNeMcjhNZJ5UbAb96SGvxUesSVO2CZtcvtEBWnHCruck8J7bCsEmjxvg8b T/Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mldCPyapcgn9G947hVwaIJyQ45F+5eXGhK+el1tvLJ8=; b=Sg5CPknt6FWxRky6VDWQUdExKQRm+mhmDaPzyeo27Cd6jlXSxWrTXWxW5IYRFHK4cO yik4hiZgNgUg/ACKyXVIGfAb/zeqRW7hqsic2SZczw9W05rnJLuVBUX7A0nDR3e2X6R1 nlmaFaGz0R9CNzRV/XiehWjv/0SQGWSwgRCgoViFZ4xvQe/qCj4XaojKxE2dPPRLH4Cd 1rtkuhyqaWo6xYsOlrj+J0y/amXRTjYMLTzcP53Ltp2SEhxMW3rlw8EqH7zr3+4FVBc1 QLWxYa4mHULNRpico7z+7fgU8rumruavPi2FAdhJUFf4+T6StTat5Gpp3KT8VsKLgPxr LF2w== X-Gm-Message-State: APjAAAW2vjKHqW/7rfMf23h/zi3DCkBDW8BhQXTY0Jd6z/HClLTz10mb E0DZeaHDcleSAWSAjMuP0PLYVg== X-Google-Smtp-Source: APXvYqyL0dYiDng908XTgug2SuSZdMY7rybUaXrvuP+ScBHz0szfbti08swemv8lNH6VIrz8JETocA== X-Received: by 2002:a37:b381:: with SMTP id c123mr9628433qkf.349.1565970851498; Fri, 16 Aug 2019 08:54:11 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id h26sm3311206qta.58.2019.08.16.08.54.10 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 16 Aug 2019 08:54:11 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C6FB4F8E-880A-4397-908E-38865D37826F Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 16 Aug 2019 11:54:10 -0400 Message-Id: <954B86B4-92A2-411A-9F45-C87CF0A4985A@fugue.com> References: <20190816152532.z1q1S%steffen@sdaoden.eu> Cc: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org In-Reply-To: <20190816152532.z1q1S%steffen@sdaoden.eu> To: Steffen Nurpmeso X-Mailer: iPhone Mail (17A568) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:54:15 -0000 --Apple-Mail-C6FB4F8E-880A-4397-908E-38865D37826F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DNSSEC lets you check that the cert you have been offered is for a key that t= he site actually uses. Of course DNSSEC can be blocked, but it can=E2=80=99t= be blocked undetectably. So with DNSSEC you can at least know that you are= under attack and decide whether to proceed.=20 It=E2=80=99s also true that sometimes state actors openly break PKI, and tha= t we can=E2=80=99t do anything about that systemically. But when state actor= s or others secretly break PKI, having a way to detect that is very benefici= al.=20 Sent from my iPhone > On Aug 16, 2019, at 11:25, Steffen Nurpmeso wrote: >=20 > =EF=BB=BFTed Lemon wrote in <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.co= m>: > |Both of those papers talk about incompetence of operation, not about \ > |technical weaknesses. Competently operated DNSSEC will not have the \ > |problems these two papers describe. Are you aware of any technical \ > |problem with using TLSA to prevent PKI attacks, or is this just FUD? >=20 > Competence does not help if governments or companies enforce some > policy. If they are willing to channel data and require > installation of a certificate in your CA pool, then the best you > can get is increased effort on their side, by introducing a shadow > DNS topology, unless i am mistaken. >=20 > I do not understand, and never (~18 years) did, why the complexity > of DNS is increased so much; instead of moving over to secure > transport that is. And if you want to sign data bundles, then > those keys could also be used, they have the potential for it, do > they. Repeatedly connect up to the root domain of your URL in > question, and collect certificates along the way, unless you have > the complete chain, which you can cache locally. Especially if > you now even pump the data as such over an already open HTTP > channel. But in general this looked to me the much more elegant > resolution (once i looked at DNSSEC and TSIG and said "no > (hopefully not)"). And much easier to implement, and by using > facilities of libraries which see many eyes. And keeping the core > protocol clean. >=20 > What do you win more than (possibly) increased complexity on the > door through the wall? But "leaving lonely people fight in dark > side streets as opposed to perceptable noise when someone enforces > entries in local CA pools"? > Just my one cent. >=20 > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) --Apple-Mail-C6FB4F8E-880A-4397-908E-38865D37826F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable DNSSEC lets you check that the cert you hav= e been offered is for a key that the site actually uses. Of course DNSSEC ca= n be blocked, but it can=E2=80=99t be blocked undetectably.  So with DN= SSEC you can at least know that you are under attack and decide whether to p= roceed. 

It=E2=80=99s also true that sometimes state= actors openly break PKI, and that we can=E2=80=99t do anything about that s= ystemically. But when state actors or others secretly break PKI, havi= ng a way to detect that is very beneficial. 

Se= nt from my iPhone

On Aug= 16, 2019, at 11:25, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
<= br>
=EF=BB=BFTed Lemon wrote in <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com>= ;:
|Both of those papers talk about incompetence of operati= on, not about \
|technical weaknesses. Competently operated= DNSSEC will not have the \
|problems these two papers desc= ribe. Are you aware of any technical \
|problem with using T= LSA to prevent PKI attacks, or is this just FUD?

= Competence does not help if governments or companies enforce some
policy.  If they are willing to channel data and require
installation of a certificate in your CA pool, then the best y= ou
can get is increased effort on their side, by introducing= a shadow
DNS topology, unless i am mistaken.

I do not understand, and never (~18 years) did, why the c= omplexity
of DNS is increased so much; instead of moving ove= r to secure
transport that is.  And if you want to sign= data bundles, then
those keys could also be used, they have= the potential for it, do
they.  Repeatedly connect up t= o the root domain of your URL in
question, and collect certi= ficates along the way, unless you have
the complete chain, w= hich you can cache locally.  Especially if
you now even= pump the data as such over an already open HTTP
channel. &n= bsp;But in general this looked to me the much more elegant
r= esolution (once i looked at DNSSEC and TSIG and said "no
(ho= pefully not)").  And much easier to implement, and by using
<= span>facilities of libraries which see many eyes.  And keeping the core=
protocol clean.

What do yo= u win more than (possibly) increased complexity on the
door t= hrough the wall?  But "leaving lonely people fight in dark
side streets as opposed to perceptable noise when someone enforces
entries in local CA pools"?
Just my one cent.

--steffen
|
|D= er Kragenbaer,           &= nbsp;    The moon bear,
|der holt sich m= unter           he cheerfu= lly and one by one
|einen nach dem anderen runter  wa.k= s himself off
|(By Robert Gernhardt)
= --Apple-Mail-C6FB4F8E-880A-4397-908E-38865D37826F-- From nobody Fri Aug 16 11:40:53 2019 Return-Path: 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 A1446120806 for ; Fri, 16 Aug 2019 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 cUdI9bj8oudL for ; Fri, 16 Aug 2019 11:40:48 -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 5B02D12009C for ; Fri, 16 Aug 2019 11:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id B52598EF for ; Fri, 16 Aug 2019 20:40:45 +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 gh9QEmtW4Pw1 for ; Fri, 16 Aug 2019 20:40:45 +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 87BFF8EE for ; Fri, 16 Aug 2019 20:40:44 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190815163938.CF9CB85D108@ary.local> <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> From: Erik Sy 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: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> Date: Fri, 16 Aug 2019 20:40:43 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003080304030307050307" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 18:40:52 -0000 This is a cryptographically signed message in MIME format. --------------ms050003080304030307050307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Ted, On 8/16/19 17:50, Ted Hardie wrote: > =C2=A0 > Yes, this is true, but I thought you asserted that it would > opportunistically attempt to use the provided records.=C2=A0 That means= it > could also leak the interest of the client in a specific resource to a > potentially malign collector at the instigation of any web site > providing the malign DNS record; that's the increase in attack surface > for the existing attack. Today, websites can already learn something about the interest of their clients in specific resources. For example, search engines learn which results a client clicked by providing the client redirects instead of direct links. Thus, I think the described attack surface does not increase with respect to links directly provided by the website supporting resolver-less DNS. Beyond this, I describe in Section 3.2.2 of the paper restrictions for DNS records retrieved via resolver-less DNS. Here, it is recommended that user agents restrict the use of unvalidated DNS records retrieved via resolver-less DNS within the context of the same website or possibly the same browser tab. This measure prevents the described leaks beyond the applied context of a website or browser tab. Thus, I do not agree that resolver-less DNS contributes to the described increase in the attack surface. Erik > =C2=A0 At the very least, that appears to require clients to cache wher= e > DNS records came from in their cache, so that they can build a > reputation for sources that supplied bad data and ignore data from > sources that gave bad data.=C2=A0 That's a far from perfect mitigation,= of > course, but it helps some. > =C2=A0 > > > =C2=A0 > > =C2=A0It also raises the risk that a client will receive a server= > > authentication from a CA not intended by the domain owner (our > friend > > the enterprise, an attacker, a government, etc.).=C2=A0 We have s= ome > > mitigations for that, but they are not complete. > > The problem you are describing is not introduced by resolver-less D= NS. > > > Agreed, but it also can't be ignored that the new source of supplied > DNS records gives a new opportunity to line up the facilities needed > for a successful attack. > > regards, > > Ted > =C2=A0 --------------ms050003080304030307050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYxODQwNDNaMC8GCSqGSIb3DQEJBDEiBCC8lQHB+oBn 0uX8h/2fctUtaJYvxfAqzBWkj9/+eLCiODBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBA7RhsnwO2Ev8rEuiPW0SIrlXWLmIBi1f9USz9 1vryO2DmfXaYt7l/dmn3OmOBDblZgVR+5xAwvfMTgmnTL6T+pnbi/zjMcHG4cGu9z/8KSBHV QrXPgqbFIypaWQ7JazM6x7zrL3cSr1P2/2RVFQIlaV1yGgGU/vgPIPyGALiGdrQM31HxnJmn rtcBAlMY0rVMpXaJ9inX619B34GZSuCT1hK3txgYJYR4+v+EvCI3CX6JfhhiZpof2v4r8gVT +M+0nJ2pMo8w2J4wL10lY5VleowRDSKoKK6VQhnrAAl+e7JTHKZBwFX5lPTVVkwMW3ld55Io 3x2MLR3bdJeanO2WAAAAAAAA --------------ms050003080304030307050307-- From nobody Fri Aug 16 12:50:21 2019 Return-Path: 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 5D08E1200D6 for ; Fri, 16 Aug 2019 12:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no 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 jZzLcrwxCzeQ for ; Fri, 16 Aug 2019 12:50:17 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EFC120090 for ; Fri, 16 Aug 2019 12:50:17 -0700 (PDT) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AEBA9892E8 for ; Fri, 16 Aug 2019 19:50:16 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Date: Fri, 16 Aug 2019 19:50:15 +0000 Message-ID: <7458927.46QQVHFPpo@linux-9daj> Organization: none In-Reply-To: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> References: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 19:50:19 -0000 On Friday, 16 August 2019 18:40:43 UTC Erik Sy wrote: > ... > > Beyond this, I describe in Section 3.2.2 of the paper restrictions for > DNS records retrieved via resolver-less DNS. Here, it is recommended > that user agents restrict the use of unvalidated DNS records retrieved > via resolver-less DNS within the context of the same website or possibly > the same browser tab. This measure prevents the described leaks beyond > the applied context of a website or browser tab. Thus, I do not agree > that resolver-less DNS contributes to the described increase in the > attack surface. > > Erik 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? i ask, because of this: > ;; ANSWER SECTION: > www.microsoft.com. CNAME www.microsoft.com-c-3.edgekey.net. > www.microsoft.com-c-3.edgekey.net. CNAME www.microsoft.com- c-3.edgekey.net.globalredir.akadns.net. > www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. CNAME e13678.dspb.akamaiedge.net. > e13678.dspb.akamaiedge.net. A 23.197.97.139 my stub resolvers trust this from their recursive servers. but such CNAME chains are ignored by recursive servers, since the authority can only speak for one zone at a time. i'd like to be sure that i understand the rules you are proposing for the web equivalent of all this. -- Paul From nobody Fri Aug 16 13:25:47 2019 Return-Path: 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 2C04B12008B for ; Fri, 16 Aug 2019 13:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 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, URI_HEX=0.1] 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 V7wKfBDTQGm4 for ; Fri, 16 Aug 2019 13:25:43 -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 87A37120018 for ; Fri, 16 Aug 2019 13:25:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 7B36246 for ; Fri, 16 Aug 2019 22:25:41 +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 PX8qezEvhl+5 for ; Fri, 16 Aug 2019 22:25:41 +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 880F145 for ; Fri, 16 Aug 2019 22:25:40 +0200 (CEST) To: resolverless-dns@ietf.org References: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> <7458927.46QQVHFPpo@linux-9daj> Reply-To: sy@informatik.uni-hamburg.de From: Erik Sy 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: <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de> Date: Fri, 16 Aug 2019 22:25:39 +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: <7458927.46QQVHFPpo@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090509040602020506080505" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 20:25:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090509040602020506080505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Paul, On 8/16/19 21:50, Paul Vixie wrote: > On Friday, 16 August 2019 18:40:43 UTC Erik Sy wrote: >> ... >> >> Beyond this, I describe in Section 3.2.2 of the paper restrictions for= >> DNS records retrieved via resolver-less DNS. Here, it is recommended >> that user agents restrict the use of unvalidated DNS records retrieved= >> via resolver-less DNS within the context of the same website or possib= ly >> the same browser tab. This measure prevents the described leaks beyond= >> the applied context of a website or browser tab. Thus, I do not agree >> that resolver-less DNS contributes to the described increase in the >> attack surface. >> >> Erik > does this mean an fbcdn.net link occuring inside a facebook.com object = would=20 > require a real DNS lookup, and that any fbcdn.net DNS data included in = the=20 > 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 look= up. 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 authenticati= on. Erik > i ask, because of this: > >> ;; ANSWER SECTION: >> www.microsoft.com. CNAME www.microsoft.com-c-3.edgekey.net. >> www.microsoft.com-c-3.edgekey.net. CNAME www.microsoft.com- > c-3.edgekey.net.globalredir.akadns.net. >> www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. CNAME=20 > e13678.dspb.akamaiedge.net. >> e13678.dspb.akamaiedge.net. A 23.197.97.139 > my stub resolvers trust this from their recursive servers. but such CNA= ME=20 > chains are ignored by recursive servers, since the authority can only s= peak=20 > for one zone at a time. i'd like to be sure that i understand the rules= you=20 > are proposing for the web equivalent of all this. > --------------ms090509040602020506080505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYyMDI1MzlaMC8GCSqGSIb3DQEJBDEiBCAwInlc95hP 7B3t4uAhc7SOpa1jSvFvvIebSpJb0hf+XjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCknNTeynDU2y5WoNrfLzJTLXOfJilt5+phzf3I HrwWDzNeIBMxc5dpvtx0T09TWcKAToWn43eNiMQ2+kYHj0mgmaNjOPu8OyOqvfb/VPCMT5Mf msLk53eJ905ZAKhn/rB7v4+gOFUDR6WwAiK45MMxBQXJy0toXFCAJFlRZYJ+i4lSHlAcr60u TdSrLj48Gk0cexn6I63J12L9uVOvuYFO2bAlxLLotW4s5zPp3DTiU5BHtJbEBhT/unGjImUC JX+ELdFfc9LaIJ7q+rCmECqRAzwyGheH0aXLUOkyd0q5Vi+9lyrjhUpm4Q4PgfIBFM5Pxs2z dUcf3tFFLi0G9TUmAAAAAAAA --------------ms090509040602020506080505-- From nobody Fri Aug 16 13:29:32 2019 Return-Path: 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 D10F41200F5 for ; Fri, 16 Aug 2019 13:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.com 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 0pF8vuev50lL for ; Fri, 16 Aug 2019 13:29:28 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562AB1200C5 for ; Fri, 16 Aug 2019 13:29:28 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id 18so8758639ioe.10 for ; Fri, 16 Aug 2019 13:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3q33XgZTG+flkN52AMmXnkxSUZLYimpFwzJhW03tuXs=; b=DB2auFAVEQYsNltuUCc7IcUJv3knM4GbIXHxKItWDunBYc9BULHVozqyJoGIzonEwV TvBi6Xtk1gBTdGJCCGC7aqKJA85/gK/29tLFnGHrCYlCLtVfawxAW3vYmLFrruM8rgCi cPQznS6z7n6wm05opI1ZlCaTqxPsnugEG6E7Y9IjWK1NHwCSX9hiNZ/N9aXi8rAHOdFJ WJhbuK5Ssz/gOIHeEoHqJLOLEx41RslOgp2sJEhX9XxBn+WB73IK7+zlt8EQd7hvdo7n tj+AFNFukxNQYSlr8g78P2EO+2mzTiDG2aNiASj1FWZpnU/YJHbpjKObLHzbuB29Ai2O A4tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3q33XgZTG+flkN52AMmXnkxSUZLYimpFwzJhW03tuXs=; b=eCxJkxidoFOcInQO8xLzoP2UwlcK7gMIcFmP7eeputzDlNC9LtZouU0WtZkasTPPyz GsFyC1wpjV/fe9iKj+ENq0vk7eZNeo0wav5mqPB/gR2pc4nsEViH54KTElbBfQ5/eVz9 DcrMfRhzUsnANuTFfx7brmQ1j94bo9M8iUAfLG9sNKkAckP2r/wRrJ4ynsAfcrNQdVVV sfFYeAIrYV2pOMUjX9bSHw/kGERhRMINE65z3HtVG9JP8Ck6KxKgyaejQnVFbD7pdJ86 9eHj9UowoKTF0MEw97c+JkOnA5WuVeUGiNXUZ04ch4lD0/Si+mCiSDJL7B8K5QMKIqxJ rp9w== X-Gm-Message-State: APjAAAUVfLV673BRofpv6vcGDs34nIEA8E45fAv7vLtrqrj3FgVYzqYP 8kqwKjGSbK6ATImp4SGM0TbHpB2V11tCEJMYJORxwg== X-Google-Smtp-Source: APXvYqz7GsPljpNcR3Nv/fD7XzMmzrjM7PL1LeqCi9oi7WivzsLkI7j3XsM3NFzKJcRg0KxEE6W+vo60et+bp/qmHfU= X-Received: by 2002:a6b:790d:: with SMTP id i13mr12537847iop.27.1565987367399; Fri, 16 Aug 2019 13:29:27 -0700 (PDT) MIME-Version: 1.0 References: <20190815163938.CF9CB85D108@ary.local> <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de> <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> In-Reply-To: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de> From: Ted Hardie Date: Fri, 16 Aug 2019 13:29:01 -0700 Message-ID: To: sy@informatik.uni-hamburg.de Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="000000000000c1b6d1059041d8e6" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 20:29:31 -0000 --000000000000c1b6d1059041d8e6 Content-Type: text/plain; charset="UTF-8" Hi Erik, Thanks for the time you've taken with your replies. It appears we simply disagree, as I believe the measure does increase the attack surface, especially in the cases where the measures to limit the supplied records are not (for example, I think "same browser tab" is too lax). I appreciate the opportunity to discuss this, however, despite our disagreement. regards, Ted On Fri, Aug 16, 2019 at 11:40 AM Erik Sy wrote: > Hi Ted, > > On 8/16/19 17:50, Ted Hardie wrote: > > > > Yes, this is true, but I thought you asserted that it would > > opportunistically attempt to use the provided records. That means it > > could also leak the interest of the client in a specific resource to a > > potentially malign collector at the instigation of any web site > > providing the malign DNS record; that's the increase in attack surface > > for the existing attack. > > Today, websites can already learn something about the interest of their > clients in specific resources. For example, search engines learn which > results a client clicked by providing the client redirects instead of > direct links. Thus, I think the described attack surface does not > increase with respect to links directly provided by the website > supporting resolver-less DNS. > > Beyond this, I describe in Section 3.2.2 of the paper restrictions for > DNS records retrieved via resolver-less DNS. Here, it is recommended > that user agents restrict the use of unvalidated DNS records retrieved > via resolver-less DNS within the context of the same website or possibly > the same browser tab. This measure prevents the described leaks beyond > the applied context of a website or browser tab. Thus, I do not agree > that resolver-less DNS contributes to the described increase in the > attack surface. > > Erik > > > At the very least, that appears to require clients to cache where > > DNS records came from in their cache, so that they can build a > > reputation for sources that supplied bad data and ignore data from > > sources that gave bad data. That's a far from perfect mitigation, of > > course, but it helps some. > > > > > > > > > > It also raises the risk that a client will receive a server > > > authentication from a CA not intended by the domain owner (our > > friend > > > the enterprise, an attacker, a government, etc.). We have some > > > mitigations for that, but they are not complete. > > > > The problem you are describing is not introduced by resolver-less > DNS. > > > > > > Agreed, but it also can't be ignored that the new source of supplied > > DNS records gives a new opportunity to line up the facilities needed > > for a successful attack. > > > > regards, > > > > Ted > > > > -- > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns > --000000000000c1b6d1059041d8e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

Thanks for the time= you've taken with your replies.=C2=A0 It appears we simply disagree, a= s I believe the measure does increase the attack surface, especially in the= cases where the measures to limit the supplied records are not (for exampl= e, I think "same browser tab" is too lax).=C2=A0 I appreciate the= opportunity to discuss this, however, despite our disagreement.
=
regards,

Ted

On Fri, Aug 1= 6, 2019 at 11:40 AM Erik Sy <sy@informatik.uni-hamburg.de> wrote:
Hi Ted,

On 8/16/19 17:50, Ted Hardie wrote:
> =C2=A0
> Yes, this is true, but I thought you asserted that it would
> opportunistically attempt to use the provided records.=C2=A0 That mean= s it
> could also leak the interest of the client in a specific resource to a=
> potentially malign collector at the instigation of any web site
> providing the malign DNS record; that's the increase in attack sur= face
> for the existing attack.

Today, websites can already learn something about the interest of their
clients in specific resources. For example, search engines learn which
results a client clicked by providing the client redirects instead of
direct links. Thus, I think the described attack surface does not
increase with respect to links directly provided by the website
supporting resolver-less DNS.

Beyond this, I describe in Section 3.2.2 of the paper restrictions for
DNS records retrieved via resolver-less DNS. Here, it is recommended
that user agents restrict the use of unvalidated DNS records retrieved
via resolver-less DNS within the context of the same website or possibly the same browser tab. This measure prevents the described leaks beyond
the applied context of a website or browser tab. Thus, I do not agree
that resolver-less DNS contributes to the described increase in the
attack surface.

Erik

> =C2=A0 At the very least, that appears to require clients to cache whe= re
> DNS records came from in their cache, so that they can build a
> reputation for sources that supplied bad data and ignore data from
> sources that gave bad data.=C2=A0 That's a far from perfect mitiga= tion, of
> course, but it helps some.
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0> =C2=A0
>=C2=A0 =C2=A0 =C2=A0> =C2=A0It also raises the risk that a client wi= ll receive a server
>=C2=A0 =C2=A0 =C2=A0> authentication from a CA not intended by the d= omain owner (our
>=C2=A0 =C2=A0 =C2=A0friend
>=C2=A0 =C2=A0 =C2=A0> the enterprise, an attacker, a government, etc= .).=C2=A0 We have some
>=C2=A0 =C2=A0 =C2=A0> mitigations for that, but they are not complet= e.
>
>=C2=A0 =C2=A0 =C2=A0The problem you are describing is not introduced by= resolver-less DNS.
>
>
> Agreed, but it also can't be ignored that the new source of suppli= ed
> DNS records gives a new opportunity to line up the facilities needed > for a successful attack.
>
> regards,
>
> Ted
> =C2=A0

--
Resolverless-dns mailing list
Resolverless= -dns@ietf.org
https://www.ietf.org/mailman/listinfo/resolver= less-dns
--000000000000c1b6d1059041d8e6-- From nobody Fri Aug 16 13:30:55 2019 Return-Path: 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 1B8ED12008B for ; Fri, 16 Aug 2019 13:30:53 -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, 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 eydMRaREMexT for ; Fri, 16 Aug 2019 13:30:51 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F677120018 for ; Fri, 16 Aug 2019 13:30:51 -0700 (PDT) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D4F90892E8 for ; Fri, 16 Aug 2019 20:30:50 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Date: Fri, 16 Aug 2019 20:30:49 +0000 Message-ID: <5555002.tMPyTYP4cW@linux-9daj> Organization: none In-Reply-To: <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de> References: <7458927.46QQVHFPpo@linux-9daj> <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 20:30:53 -0000 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 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. -- Paul From nobody Fri Aug 16 13:50:13 2019 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 16 Aug 2019 22:50:06 +0200 (CEST) From: Erik Sy To: resolverless-dns@ietf.org References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 20:50:12 -0000 This is a cryptographically signed message in MIME format. --------------ms030905070307090103050701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB 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 objec= t >>> 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= =2E 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 with= in >> 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. > --------------ms030905070307090103050701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYyMDUwMDVaMC8GCSqGSIb3DQEJBDEiBCCgHZH7qj9z loU1GPevI8NDKXkyFESN7uBJwPNdg4RAaDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQA8UIkhyQaKTdjeg2m8eXiGpg5dXj7bk1kd4RiK f4xUpyJyc2TOQT+KVpx4C503+h1R+ao+hxprlKeHztmL7QfL+l+0xjFh5JGYzWRU5q9he6XO L0XIds+7Hi0O71hAWew5uha6zbVxiJt/NhXaEEVnky8bJW1rLWM93NSiMvwuzTJBemLs8HBA 8hnX3uclTqTsUOGrvO2XxgT69nt2bjiqVjiqd8CgUYudYv3NF9l05nkXWEQKWkVb7I3QgPKL VH38zBtbcZogm5kYaAUR0rnYasrF/Hn0B5Uex2BpAyR0/1VC4qsPCfjbxRl6/UdutuJ4d6ij WdAVF44HyL73DRAmAAAAAAAA --------------ms030905070307090103050701-- From nobody Fri Aug 16 14:02:54 2019 Return-Path: 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 D796512007C for ; Fri, 16 Aug 2019 14:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 kIs3G86-Dl4h for ; Fri, 16 Aug 2019 14:02:51 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895B0120018 for ; Fri, 16 Aug 2019 14:02:51 -0700 (PDT) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1A855892E8; Fri, 16 Aug 2019 21:02:50 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Fri, 16 Aug 2019 21:02:49 +0000 Message-ID: <16840451.Gnsi7N2eSB@linux-9daj> Organization: none In-Reply-To: <16db6a04-5c24-b35c-da0f-666e10a2136b@informatik.uni-hamburg.de> References: <5555002.tMPyTYP4cW@linux-9daj> <16db6a04-5c24-b35c-da0f-666e10a2136b@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 21:02:53 -0000 On Friday, 16 August 2019 20:50:05 UTC Erik Sy wrote: > > 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? nothing which can be abused won't be. your design has at least one flaw that a red team would find for you if you had one. instead you've got us. there is no reason for a web client to trust a web server to provide correct information about dns outside of its same-origin. that data could be stale, accidentally wrong, or purposefully wrong. this problem is why dnssec exists. i believe i've seen you argue elsewhere in this thread as to the authenticity guarantees of the TLS (HTTPS) path from the web client to the web server. i don't agree with that view, and the DANE (TLSA RR) approach is necessary. however, even if i agreed, i would decline a design which called for the client to trust the server to have accurate information about any domain outside of the same-origin policy which we already trust for cookie coverage. * * * i'm also waiting to see a problem statement that justifies resolverless dns, and if we get past that, i'll want to see how the network operator's policies for dns monitoring and filtering will be reliably detected, and respected. -- Paul From nobody Fri Aug 16 14:35:30 2019 Return-Path: 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 D1F2D12007C for ; Fri, 16 Aug 2019 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 ck7RwP7uykYb for ; Fri, 16 Aug 2019 14:35:27 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 20A4E120018 for ; Fri, 16 Aug 2019 14:35:27 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192] port 37090) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id x7GLZQp1010124 for ; Fri, 16 Aug 2019 17:35:26 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.7/8.14.7/Submit) with ESMTP id x7GLZPlf027028 for ; Fri, 16 Aug 2019 17:35:26 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: resolverless-dns@ietf.org References: <5555002.tMPyTYP4cW@linux-9daj> <16db6a04-5c24-b35c-da0f-666e10a2136b@informatik.uni-hamburg.de> <16840451.Gnsi7N2eSB@linux-9daj> In-Reply-To: <16840451.Gnsi7N2eSB@linux-9daj> X-In-Reply-To: Your message of Fri, 16 Aug 2019 21:02:49 -0000 From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 16 Aug 2019 17:35:25 -0400 Message-ID: <27027.1565991325@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2019-08-16 17:35:26 EDT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 21:35:29 -0000 Paul Vixie writes: > i'll want to see how the network operator's policies for > dns monitoring and filtering will be reliably detected, > and respected. I would think this to be an impossible task; if I as a network operator am redirecting all port 53 traffic to my resolvers, which use various filtering policies to, for example, redirect queries for known phishing and malware sites to my local "don't be phished" web page, what on earth mechanism could possibly exist that could mirror my policies in this context? While I believe in the bona fide of the people advocating for resolverless DNS, and I don't doubt that there are performance bottlenecks that could be alleviated with such a scheme, as a sysadmin I feel almost as if these designs were specifically created to prevent me from protecting my users. :-( Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri Aug 16 14:45:14 2019 Return-Path: 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 347DC120071 for ; Fri, 16 Aug 2019 14:45:11 -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, 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 jBCQh8fGDw43 for ; Fri, 16 Aug 2019 14:45:09 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC2B120018 for ; Fri, 16 Aug 2019 14:45:09 -0700 (PDT) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 14594892E8; Fri, 16 Aug 2019 21:45:09 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Cc: Anne Bennett Date: Fri, 16 Aug 2019 21:45:08 +0000 Message-ID: <9323236.5EVOHOzQma@linux-9daj> Organization: none In-Reply-To: <27027.1565991325@vindemiatrix.encs.concordia.ca> References: <16840451.Gnsi7N2eSB@linux-9daj> <27027.1565991325@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 21:45:11 -0000 On Friday, 16 August 2019 21:35:25 UTC Anne Bennett wrote: > Paul Vixie writes: > > i'll want to see how the network operator's policies for > > dns monitoring and filtering will be reliably detected, > > and respected. > > I would think this to be an impossible task; if I as a network > operator am redirecting all port 53 traffic to my resolvers, > which use various filtering policies to, for example, redirect > queries for known phishing and malware sites to my local > "don't be phished" web page, what on earth mechanism could > possibly exist that could mirror my policies in this context? this draft in another wg appears to be an attempt at such: https://datatracker.ietf.org/doc/draft-sah-resolver-information/ i don't know if it can meet the "reliably detected" threshold though. > While I believe in the bona fide of the people advocating for > resolverless DNS, and I don't doubt that there are performance > bottlenecks that could be alleviated with such a scheme, as a > sysadmin I feel almost as if these designs were specifically > created to prevent me from protecting my users. :-( i know that feeling. but i think what's happened is the next generation of internet technologists have taken an interest in dns, without ever having tried to secure it or defend it, or its applications. not knowing what they don't know, their proposals seem more reasonable to them than to me. see also: http://dnstap.info/ and: https://dnsrpz.info/ -- Paul From nobody Fri Aug 16 14:52:52 2019 Return-Path: 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 10A3D120071 for ; Fri, 16 Aug 2019 14:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 GGB8v6gVFIWm for ; Fri, 16 Aug 2019 14:52:47 -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 7D39E120052 for ; Fri, 16 Aug 2019 14:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id D76CE332; Fri, 16 Aug 2019 23:52:44 +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 bgN-BmW2Y3He; Fri, 16 Aug 2019 23:52:44 +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 93E22331; Fri, 16 Aug 2019 23:52:41 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Paul Vixie , resolverless-dns@ietf.org References: <5555002.tMPyTYP4cW@linux-9daj> <16db6a04-5c24-b35c-da0f-666e10a2136b@informatik.uni-hamburg.de> <16840451.Gnsi7N2eSB@linux-9daj> From: Erik Sy 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: <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> Date: Fri, 16 Aug 2019 23:52:40 +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: <16840451.Gnsi7N2eSB@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070008090905090605030709" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 21:52:50 -0000 This is a cryptographically signed message in MIME format. --------------ms070008090905090605030709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/16/19 23:02, Paul Vixie wrote: > * * * > > i'm also waiting to see a problem statement that justifies resolverless= dns,=20 > and if we get past that, i'll want to see how the network operator's po= licies=20 > for dns monitoring and filtering will be reliably detected, and respect= ed. Clients using a traditional DNS resolver do not care about a validation of those DNS records. Resolver-less DNS changes this practice and applies validation strategies for DNS records to improve the clients security. In this thread, we talked about possible privacy drawbacks of resolver-less DNS. However, did we talk about the privacy risks of using a traditional DNS resolver? They can monitor the entire browsing activities of a user and present the real privacy problem. Finally, DNS lookups introduce additional delay to connection establishments on the web. Especially, for clients on high-latency access networks this delay is quite significant. In my view, user and service provider benefit from resolver-less DNS as it reduces that delay and contributes to an accelerated retrieval of websites. Erik --------------ms070008090905090605030709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYyMTUyNDFaMC8GCSqGSIb3DQEJBDEiBCDIzQX5LCjk eg76NNrO3uMBOOO536wJVuGMkwFBq/ARrjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQC+E4YzfXXuaIYBpU590c5sqYkfrIdpU4dbq/C/ +OZL4h1dj9rFuR1ao5U3grzqonOEmwmh9ERP3yyLD0FbJ4ThsGXCVeSVsEO6DpQpcJZALebZ 3jvcracbyqN5L9JhvT9C785MXInHPJV9ydmoyRdgRBFEgmjYfZIO45p+7v/nqA0M2GAwaFmS DUQmpymx41SE8GFGy0CWnxW4B3inCyKOKEmarGhT0SArjPt++YQVbSGzkpOI3VrCbsYAjeMM JfdRAYfE0vMFplt56ocrI1Ktl5H1CmaRfE5tiYJMhL3HEFGNDlB3DgmO8beAaCCm1hvFMsV9 OqGrTQ49hfeD1GvDAAAAAAAA --------------ms070008090905090605030709-- From nobody Fri Aug 16 22:40:01 2019 Return-Path: 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 786D812012C for ; Fri, 16 Aug 2019 22:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 h1NdPfjDB7cJ for ; Fri, 16 Aug 2019 22:39:58 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17321120113 for ; Fri, 16 Aug 2019 22:39:58 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 26EC5892E8; Sat, 17 Aug 2019 05:39:56 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Sat, 17 Aug 2019 05:39:55 +0000 Message-ID: <6216510.zdPCGfSLMl@linux-9daj> Organization: none In-Reply-To: <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> References: <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 05:40:00 -0000 On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote: > On 8/16/19 23:02, Paul Vixie wrote: > > * * * > > > > i'm also waiting to see a problem statement that justifies resolverless > > dns, and if we get past that, i'll want to see how the network operator's > > policies for dns monitoring and filtering will be reliably detected, and > > respected. > Clients using a traditional DNS resolver do not care about a validation > of those DNS records. i have significant evidence to the contrary. > Resolver-less DNS changes this practice and > applies validation strategies for DNS records to improve the clients > security. your reinvention will not be universally welcomed as a saviour. > In this thread, we talked about possible privacy drawbacks of > resolver-less DNS. However, did we talk about the privacy risks of using > a traditional DNS resolver? They can monitor the entire browsing > activities of a user and present the real privacy problem. DoT (RFC 7858) corrects that privacy problem and is being deployed. > Finally, DNS lookups introduce additional delay to connection > establishments on the web. Especially, for clients on high-latency > access networks this delay is quite significant. In my view, user and > service provider benefit from resolver-less DNS as it reduces that delay > and contributes to an accelerated retrieval of websites. you are not the first designer to prioritize performance over safety and correctness, or to offer one-off solutions which do not help to create a unified architecture where each part leverages the whole. please respect the network operator's wishes if local DNS policy filtering and/or monitoring is a requirement. please do not define a protocol which offers, or accepts, non-same-origin data. i will be happy to meet you on a teleconference to discuss these matters. -- Paul From nobody Sat Aug 17 12:35:33 2019 Return-Path: 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 A14D012009C for ; Sat, 17 Aug 2019 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 6r1NQFeU6ZGq for ; Sat, 17 Aug 2019 12:35:28 -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 E6C4012003F for ; Sat, 17 Aug 2019 12:35:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id DAFF9D6 for ; Sat, 17 Aug 2019 21:35:25 +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 R-ihZ41K9FZy for ; Sat, 17 Aug 2019 21:35:25 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB746.versanet.de [87.123.183.70]) (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 B7760D5 for ; Sat, 17 Aug 2019 21:35:23 +0200 (CEST) To: resolverless-dns@ietf.org References: <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> <6216510.zdPCGfSLMl@linux-9daj> From: Erik Sy 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: Date: Sat, 17 Aug 2019 21:35:23 +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: <6216510.zdPCGfSLMl@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030308060203000009070305" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 19:35:31 -0000 This is a cryptographically signed message in MIME format. --------------ms030308060203000009070305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/17/19 07:39, Paul Vixie wrote: > On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote: >> On 8/16/19 23:02, Paul Vixie wrote: >>> * * * >>> >>> i'm also waiting to see a problem statement that justifies resolverle= ss >>> dns, and if we get past that, i'll want to see how the network operat= or's >>> policies for dns monitoring and filtering will be reliably detected, = and >>> respected. >> Clients using a traditional DNS resolver do not care about a validatio= n >> of those DNS records. > i have significant evidence to the contrary. Can you please share your evidence? >> In this thread, we talked about possible privacy drawbacks of >> resolver-less DNS. However, did we talk about the privacy risks of usi= ng >> a traditional DNS resolver? They can monitor the entire browsing >> activities of a user and present the real privacy problem. > DoT (RFC 7858) corrects that privacy problem and is being deployed. The privacy problem is that a significant share of DNS resolvers monitor the users' online activities, aggregate these data in user profiles and use these profiles within behavioral advertising or share these user profiles with other parties. Here [1], you can find a comparative analysis of public DNS resolver privacy policies substantiating my claims= =2E Transport encryption for DNS records does not mitigate the privacy problem presented by DNS resolvers. Indeed, DoT facilitates the linking of DNS queries to specific user profiles. Previously, machine learning based on behavioral DNS pattern was required to reidentify a user after a change of its IP address [2]. DoT and DoH allow the DNS resolver to link user activities precisely based on TLS session resumption because these protocols compensate the costs of a full TLS handshake across several resumed sessions [3]. Thus, DoT and DoH do not contribute mitigating the privacy problem centering around DNS resolver. Erik [1] https://onlinelibrary.wiley.com/doi/pdf/10.1002/poi3.195 [2] https://svs.informatik.uni-hamburg.de/publications/2013/2013-04-10HBF_Beh= avior-based-tracking-with-dns-traffic.pdf [3] https://arxiv.org/pdf/1810.07304.pdf --------------ms030308060203000009070305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTcxOTM1MjNaMC8GCSqGSIb3DQEJBDEiBCCxLKOxurb8 hPpUMEZLEP1ZC7aVq4GVmQA3INMUfB4XnTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBLLZAe3J1PuEtMFZmljcWZhBc3KCbf3zaMHCAs tXTsXma1lwj0iJptJvuABzaXNeL/b8yOQrfleeXCFK6JOa21PGG0VL9EnTAPQ6U9mngwmHny lUpKf+BXXW/ScASXsaB+P9VfnxGaWH3bWrI5oHXPVx3xCgv1Wu6EpHZofYsGhWqivu/VnZBo zwuFgdkO+MZlKNFsXxptGyjcO0drL/uHttF4CWlmArWMFB5SHp2/neKmS9LSuYUE1OnnKch+ 27FoHhLVO/9pobQ+CjDIFEfREbaX5JpU0X2PPtgJUOL6uP9l3S9JwTrjTuFx7GLglr2d/U+7 fhITBk9Nn0fkftP4AAAAAAAA --------------ms030308060203000009070305-- From nobody Sat Aug 17 13:20:55 2019 Return-Path: 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 919FB120118 for ; Sat, 17 Aug 2019 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Eo8Ulr9W0EeZ for ; Sat, 17 Aug 2019 13:20:51 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 A300B12007A for ; Sat, 17 Aug 2019 13:20:51 -0700 (PDT) Received: by sdaoden.eu (Postfix, from userid 1000) id 018C816054; Sat, 17 Aug 2019 22:20:49 +0200 (CEST) Date: Sat, 17 Aug 2019 22:20:48 +0200 From: Steffen Nurpmeso To: Erik Sy Cc: resolverless-dns@ietf.org, Steffen Nurpmeso Message-ID: <20190817202048.7FUTd%steffen@sdaoden.eu> In-Reply-To: References: <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> <6216510.zdPCGfSLMl@linux-9daj> Mail-Followup-To: Erik Sy , resolverless-dns@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.14-31-g02ec9e48 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 20:20:54 -0000 Erik Sy wrote in : |On 8/17/19 07:39, Paul Vixie wrote: |> On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote: |>> On 8/16/19 23:02, Paul Vixie wrote: ... |>> Clients using a traditional DNS resolver do not care about a validation |>> of those DNS records. |> i have significant evidence to the contrary. |Can you please share your evidence? |>> In this thread, we talked about possible privacy drawbacks of |>> resolver-less DNS. However, did we talk about the privacy risks of using |>> a traditional DNS resolver? They can monitor the entire browsing |>> activities of a user and present the real privacy problem. |> DoT (RFC 7858) corrects that privacy problem and is being deployed. That is cool, btw., and i truly had an eruption of joy once that (these) RFC(s) came along! I personally do not really understand why this data (certificates) absolutely has to be stored in the DNS itself, but that is me and i am talking from the view of implementing the fully caching stub resolver that i once did. And so many RFCs have been produced on that topic, and exist, anyway. |The privacy problem is that a significant share of DNS resolvers monitor |the users' online activities, aggregate these data in user profiles and |use these profiles within behavioral advertising or share these user |profiles with other parties. Here [1], you can find a comparative |analysis of public DNS resolver privacy policies substantiating my claims. | |Transport encryption for DNS records does not mitigate the privacy |problem presented by DNS resolvers. Indeed, DoT facilitates the linking |of DNS queries to specific user profiles. Previously, machine learning |based on behavioral DNS pattern was required to reidentify a user after |a change of its IP address [2]. DoT and DoH allow the DNS resolver to |link user activities precisely based on TLS session resumption because |these protocols compensate the costs of a full TLS handshake across |several resumed sessions [3]. |Thus, DoT and DoH do not contribute mitigating the privacy problem |centering around DNS resolver. Collecting data is a real and hard so-called business (maybe "the root of all evil to- ooday"), at least in the hard west, like the U.S.[1]. [1] https://www.schneier.com/essays/archives/2018/03/its_not_just_faceboo.html So even if HTTP/2 does its best to hide more behind crypto, and of course thinking about the issue and trying to give more privacy back to users is honourable, people have their smart phone in bedroom/toilet/car/funeral, their car is online, their household appliances are online etc. In April i bought my first new box in ten years, and out of interest installed the default Windows, for me the first since Windows 95B, and i got really frightened by the questions and, yes, services that installation asked and/or offered. (It was possible to turn all off, iirc.) In 2009 i bought an Apple (wanted one once in my life), and i still grim when i think back and recall the hundreds of megabytes of data a "software update" collection send over the internet; when i compare with the much less than 10MB that an update of the Linux and *BSD distributions take, and these are entire package collections with tens of thousands of packages. You have credit cards, and you use it. Mind you, maybe you even use amazon, facebook, twitter, paypal, or any such company, which i do not. Once this resolverless DNS came up already i seem to remember the idea to create a kind of "mini per-connection tor", at least regarding DNS data. But then you have "islands" of caching resolvers all along the way, to which you will be able to talk encrypted via TLS/DTLS soon, hopefully. (Hopefully in the sense that i put trust everywhere, and thus also in the DNS endpoint i am actually talking to. I personally would have nothing against TSIGs on data sent from it, too. And if some HTTP/2 speaking browser can use and verify DNS binary blobs coming over from the HTTP server all i personally feel about that is that those software monsters can do that and reuse the anyway open connection they sit upon, because why not. But i do not think it will heal the world, i would guess that all it will possibly do, and maybe only temporary even, is that it makes the mesh more broad. At the cost of increased complexity and even more technical aspects to adhere to; but rather a HTTP than a DNS problem, me thinks. I think that is what i wanted to say.) A nice Sunday everybody! Ciao from (and to) Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Aug 17 14:13:24 2019 Return-Path: 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 25CF112006F for ; Sat, 17 Aug 2019 14:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 E0f_dLvdbXhp for ; Sat, 17 Aug 2019 14:13:21 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2D895120041 for ; Sat, 17 Aug 2019 14:13:21 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 127EE5F42D41; Sat, 17 Aug 2019 23:13:19 +0200 (CEST) Received: from [172.19.152.61] (p54B8ABDF.dip0.t-ipconnect.de [84.184.171.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 650FB5F40329; Sat, 17 Aug 2019 23:13:19 +0200 (CEST) From: "Ralf Weber" To: "Erik Sy" Cc: resolverless-dns@ietf.org Date: Sat, 17 Aug 2019 23:13:18 +0200 X-Mailer: MailMate (1.12.5r5635) Message-ID: In-Reply-To: References: <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> <6216510.zdPCGfSLMl@linux-9daj> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 21:13:23 -0000 Moin! On 17 Aug 2019, at 21:35, Erik Sy wrote: > The privacy problem is that a significant share of DNS resolvers monitor > the users' online activities, aggregate these data in user profiles and > use these profiles within behavioral advertising or share these user > profiles with other parties. Here [1], you can find a comparative > analysis of public DNS resolver privacy policies substantiating my claims. The majority of DNS resolvers for end users are still run by ISPs and Telcos. In that paper you reference the only company that can be seen as an ISP is Level3, although there resolver in contrast to mosts ISPs is open. The other are the usual open resolver vendors. So this paper clearly misses a large part of the resolver population. And my experiences with ISPs and Telkos is that they are, probably because most of them are regulated very sensitive to privacy and data analysis for marketing and advertising. A lot of them do or let others do analytics on their data, mostly after being anonymised, for security purposes, but not more. So long -Ralf —-- Ralf Weber From nobody Sun Aug 18 09:24:09 2019 Return-Path: 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 2D3A3120111 for ; Sun, 18 Aug 2019 09:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nTVoizKo; dkim=pass (1536-bit key) header.d=taugh.com header.b=bySED5Cj 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 8apnwHkNMqPn for ; Sun, 18 Aug 2019 09:24:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9850B120091 for ; Sun, 18 Aug 2019 09:24:03 -0700 (PDT) Received: (qmail 40179 invoked from network); 18 Aug 2019 16:24:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9cf1.5d597ba1.k1908; i=printer-iecc.com@submit.iecc.com; bh=x9y/7+a+H0nibsYd6eQRswA/ngU7Y+H0Iq3TYMIQhqg=; b=nTVoizKoeIsFE7hr/QTyZHv4SLtvqIFr2bh+BEv1iZxuuHXOR8WSmd1V9WD/zQkPneQsVAqs2+Z4h92TsG50qfM0a948/otOkWyuWFo1Khq/qh6nbHu6zROaZYtGtjdmBcgsQPwTAirgjPRm4FgqjvRCR0O8OqJT4073ASKeU1pyUCkvYwLeLZ4+7TkQOqHdCRANoxHa5mZ02gosxYRQVKTFMQtHPCgUPgQA053iy87VBuZVqG9dUKiOm+bVZreY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9cf1.5d597ba1.k1908; olt=printer-iecc.com@submit.iecc.com; bh=x9y/7+a+H0nibsYd6eQRswA/ngU7Y+H0Iq3TYMIQhqg=; b=bySED5CjXxxrZXHJNatIPGXLZlYJA45+2OZDE4sdLB+yV6avG93w5TMWFcRhp2St4oUET9Cw6I8fDGRKkKW++s4Jsghz+rVXObQc74BhxmkeglLzfpb2UTap8DIQA5ekWq/cd7sXS9lCTVN6JLhT3q/Ay+NQO7jv/3d8rNhT0yMQsU+18iW8yy0EoWiQR+oUhPffZy9I/ATltE7ABU/gSystHcnIKRaCb8WPKC5vPKOOYFxUwQJ/s1PJZBiGxFYT Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 18 Aug 2019 16:24:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 069CB87313A; Sun, 18 Aug 2019 12:24:00 -0400 (EDT) Date: 18 Aug 2019 12:24:00 -0400 Message-Id: <20190818162401.069CB87313A@ary.qy> From: "John Levine" To: resolverless-dns@ietf.org Cc: sy@informatik.uni-hamburg.de In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 16:24:05 -0000 In article you write: >The privacy problem is that a significant share of DNS resolvers monitor >the users' online activities, aggregate these data in user profiles and >use these profiles within behavioral advertising or share these user >profiles with other parties. Here [1], you can find a comparative >analysis of public DNS resolver privacy policies substantiating my claims. I took a look at that paper, written by two grad students. If I were their advisor I would have handed it back to them and told them to talk to some people who understand the topic so they could fix the many painful factual errors. They got the whole WHOIS GDPR fight backward, and made the rather large leap assuming that every word in, say, Google's generic privacy policy applies to queries to 8.8.8.8. What does it mean to have an account with a DNS resolver? I'm not saying that there are no issues, but this paper is not a useful discussion of them. R's, John From nobody Mon Aug 19 00:59:02 2019 Return-Path: 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 019421200B7 for ; Mon, 19 Aug 2019 00:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 eLuJiMANDRKa for ; Mon, 19 Aug 2019 00:58:58 -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 2CE7F120072 for ; Mon, 19 Aug 2019 00:58:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 6A0EA7FD for ; Mon, 19 Aug 2019 09:58:56 +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 C6dM2DjgzKkd for ; Mon, 19 Aug 2019 09:58:56 +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 6E8837FC for ; Mon, 19 Aug 2019 09:58:54 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190818162401.069CB87313A@ary.qy> From: Erik Sy 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: <0b18b804-7ebb-bb57-917e-2a9ba5190b2b@informatik.uni-hamburg.de> Date: Mon, 19 Aug 2019 09:58:54 +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: <20190818162401.069CB87313A@ary.qy> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090906030300030502080508" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 07:59:01 -0000 This is a cryptographically signed message in MIME format. --------------ms090906030300030502080508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/18/19 18:24, John Levine wrote: > In article you write: >> The privacy problem is that a significant share of DNS resolvers monit= or >> the users' online activities, aggregate these data in user profiles an= d >> use these profiles within behavioral advertising or share these user >> profiles with other parties. Here [1], you can find a comparative >> analysis of public DNS resolver privacy policies substantiating my cla= ims. > I took a look at that paper, written by two grad students. =20 I think the term grad student is not an appropriate description for a professor at the American University in Washington, DC. From my perspective, Samantha Bradshaw [1] and Laura DeNardis [2] have a good=C2=A0= academic track record in the filed. > If I were > their advisor I would have handed it back to them and told them to > talk to some people who understand the topic so they could fix the > many painful factual errors. They got the whole WHOIS GDPR fight > backward, and made the rather large leap assuming that every word in, > say, Google's generic privacy policy applies to queries to 8.8.8.8. The authors describe this limitation in their paper. In detail, some privacy policies are too generic and lack specific information about what DNS query data was collected, used and stored. Nonetheless, the authors concluded that the privacy policies of several DNS resolvers allow using DNS queries to aggregate user data for advertising. I'm not surprised by the authors' classification of Google's DNS resolver. In my view, it is plausible that an advertising company running a large number of DNS resolvers as a free service is using the collected user data in the context of behavioral advertising. > What does it mean to have an account with a DNS resolver? > I'm not saying that there are no issues, but this paper is not a > useful discussion of them. I agree that an empirical measurement substantiating the use of prior DNS queries within behavioral advertising is certainly a stronger indication for the mentioned privacy issue than a description in the privacy policy. However, I'm not aware of prior empirical research work in that direction. In total, resolver-less DNS does still send a possibly large number of fallback DNS queries to the preconfigured DNS resolver. Following this, the main argument to support resolver-less DNS is a faster connection establishment on the web as it saves the delay caused by the traditional DNS lookups. The described privacy enhancement via resolver-less DNS is just a positive side-effect. Erik [1] https://scholar.google.de/citations?user=3DemHBI1MAAAAJ [2] https://scholar.google.de/citations?user=3DPROAnvEAAAAJ --------------ms090906030300030502080508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTkwNzU4NTRaMC8GCSqGSIb3DQEJBDEiBCBoc3GQ++bR eP5DtzsDEWAiveSDG3wx4O47vMG0R0nd+zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQC3qXDpiZYFWRp/PqnOFxgq15gaPY7NgKqZ3Iu6 UuxtaktREsL7VZTqETY549BsKPaPqZa93RIeUn04nylWmaMxplVHLT72+6CpTKVBzvGDfzPK Q3IXs2ssxlsQu7MQdPhlPqG/OA9+oCpjpi9N4+iZe0Gnz+ipcGQxf/1wpoimgtvyurEVUZ// w+GpwadsFdiLpUczU1kD3IaI7xyi6Ihtr3vbFQHEixTDL2STENocf0Qk5M5uFNIWlIYSSTC2 291wpY+4LXZbGLjo+I72nO9l3rXuLo1llBTYMZF4zK+SnepsMXlLaMYIxINCnTt8ELjHdlAk c4E+2nvcPRhZoMZLAAAAAAAA --------------ms090906030300030502080508-- From nobody Mon Aug 19 09:05:03 2019 Return-Path: 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 E356A120131 for ; Mon, 19 Aug 2019 09:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9SGMgWJ8EMRa for ; Mon, 19 Aug 2019 09:05:00 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0224E120130 for ; Mon, 19 Aug 2019 09:04:59 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id o9so5441514iom.3 for ; Mon, 19 Aug 2019 09:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NpiEHpmc/4E33QOFEqj3UG2nFnpoWITnYbuZMxvQPFs=; b=mqvwJmgv4aXe3zXTiDSArBw7AbVAEpNtv//pcOsPaDUl14RU1hNEM5zUNwVjyRumW1 ZCQF8N5GSXeRJ/oLhq9nhKQ8l24660AtrA06dDesUdUMT3nJymUGxSrDZJfGbrf7MrmK dSdsh+IF87/wsEg3cCL/fpbJQoHGtEnVD/wBCciFLtidwiOMEsqxiiZxiBRCKSCzpHQW XsrdClvfb+YxkNMUNXzcjdy6Q1jVqEs2lc1ls/XczLoWFdH5434B0XTNXhQ7H2nnNFAF 7WAFahn/PYxPJcsQsLcwIsyqEAm8a1+C3cSpZzvCFOkwqdet2DzqvM0aFfi0wnyiZykh Pmdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NpiEHpmc/4E33QOFEqj3UG2nFnpoWITnYbuZMxvQPFs=; b=KBWrXVzKZpC80Ebk/rWOqjOfQk5vy8JvGrdP7wJg//nrmBCdnEU6y0GIgHtO6f7ez4 SzURZwHtUMmUh5UN0xbPUAMdnmiOmiFIS7jbUSjhQ47VHk+xDWY5eDt7Nw4Xx023Nk2y g419jA0ysQ+6ht6bqkv5Q/iJ9xqbnwPHtol7gqqyMl9Y0U3LwXhVxO9T1yMcvK3BTeyL 73gC5fUcKeL16ZlN5MHWRp5Ib2cFqAYUe4TO/lqHfMX13Qm+dcASbHYtF1rU4kSSSmMt 4sDCFCnaQ+R7B+nHU9cwQ/j5jkVe74SdnMhZh+pDjg2QoSygz2C/LygJWLyMuIn8YREQ eG2Q== X-Gm-Message-State: APjAAAWJA+Pvh90d4xXsGdT7YyJEGv9RO0C1w9CDpMLSA3jlA+qpImOR FZE4zd9C0zRc5boRmb4Rv2WwNsaZsoVfjiiy09o= X-Google-Smtp-Source: APXvYqw+8KqTl08GIuFiqT1SjqJMDFtDqQVXAV0KVScOHIpoao7t1Np6tbivSEwIdOfxWM8vIn/vgA8xcbiblL8FEx8= X-Received: by 2002:a02:5105:: with SMTP id s5mr27169341jaa.42.1566230699056; Mon, 19 Aug 2019 09:04:59 -0700 (PDT) MIME-Version: 1.0 References: <20190818162401.069CB87313A@ary.qy> <0b18b804-7ebb-bb57-917e-2a9ba5190b2b@informatik.uni-hamburg.de> In-Reply-To: <0b18b804-7ebb-bb57-917e-2a9ba5190b2b@informatik.uni-hamburg.de> From: Ted Hardie Date: Mon, 19 Aug 2019 09:04:31 -0700 Message-ID: To: sy@informatik.uni-hamburg.de Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000007424a805907a80b2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 16:05:02 -0000 --0000000000007424a805907a80b2 Content-Type: text/plain; charset="UTF-8" Hi Erik, On Mon, Aug 19, 2019 at 12:59 AM Erik Sy wrote: > > I'm not surprised by the authors' classification of Google's DNS > resolver. In my view, it is plausible that an advertising company > running a large number of DNS resolvers as a free service is using the > collected user data in the context of behavioral advertising. > > Google has published specific information on how the DNS logs are processed: https://developers.google.com/speed/public-dns/privacy so there is no need to guess. regards, Ted > --0000000000007424a805907a80b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

On Mon, Aug 19, 2019 at 12:59= AM Erik Sy <sy@informat= ik.uni-hamburg.de> wrote:

I'm not surprised by the authors' classification of Google's DN= S
resolver. In my view, it is plausible that an advertising company
running a large number of DNS resolvers as a free service is using the
collected user data in the context of behavioral advertising.


Google has published specific informat= ion on how the DNS logs are processed:


so there i= s no need to guess.

regards,

<= div>Ted


--0000000000007424a805907a80b2-- From nobody Mon Aug 19 09:10:58 2019 Return-Path: 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 08429120043 for ; Mon, 19 Aug 2019 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 xSEj-DvVzEfU for ; Mon, 19 Aug 2019 09:10:50 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6512016E for ; Mon, 19 Aug 2019 09:10:50 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192] port 48337) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id x7JGAmAQ021371 for ; Mon, 19 Aug 2019 12:10:49 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.7/8.14.7/Submit) with ESMTP id x7JGAmQF024531 for ; Mon, 19 Aug 2019 12:10:48 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: resolverless-dns@ietf.org References: <16840451.Gnsi7N2eSB@linux-9daj> <27027.1565991325@vindemiatrix.encs.concordia.ca> <9323236.5EVOHOzQma@linux-9daj> In-Reply-To: <9323236.5EVOHOzQma@linux-9daj> X-In-Reply-To: Your message of Fri, 16 Aug 2019 21:45:08 -0000 From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Mon, 19 Aug 2019 12:10:48 -0400 Message-ID: <24529.1566231048@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2019-08-19 12:10:49 EDT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 16:10:53 -0000 PV = Paul Vixie AB = Anne Bennett ES = Erik Sy PV>>> i'll want to see how the network operator's policies for PV>>> dns monitoring and filtering will be reliably detected, PV>>> and respected. AB>> I would think this to be an impossible task; PV> this draft in another wg appears to be an attempt at such: PV> https://datatracker.ietf.org/doc/draft-sah-resolver-information/ PV> PV> i don't know if it can meet the "reliably detected" threshold though. I took a quick look at the above draft; it specifies a method for enquiring about "features of a recursive resolver", but gives no ideas or guidance as to what such features might consist of, aside from a brief sentence fragment in the abstract, "such as whether they perform DNSSEC validation or are available over transports other than what is defined in RFC 1035". It seems to me straightforward to use this mechanism to supply the information *that* a resolver applies filtering, but I don't see how it could reasonably *describe* the filtering, since such a description would essentially almost *be* the filtering. I think your polite assumption that it could be possible for resolverless DNS to respect a network operator's policies for DNS filtering is, well, polite. ;-) ... which brings us to: ES>> we talked about possible privacy drawbacks of resolver-less ES>> DNS. However, did we talk about the privacy risks of using a ES>> traditional DNS resolver? They can monitor the entire browsing ES>> activities of a user and present the real privacy problem. PV> DoT (RFC 7858) corrects that privacy problem and is being deployed. I dispute the idea that DNS over TLS addresses the privacy problem of the resolver operator having access to all of a user's DNS queries. That being said, I think that stating that traditional DNS has the "real privacy problem", and implying that resolverless DNS doesn't suffer from a similar problem, is disingenuous. If I ask a question and expect an answer, *someone* has to hear my question! Who would I rather trust: an ISP whose services I pay for, or a commercial web site where most likely, I *am* the product? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Mon Aug 19 09:29:18 2019 Return-Path: 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 29300120862 for ; Mon, 19 Aug 2019 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 uFSgvZT5EfhS for ; Mon, 19 Aug 2019 09:29:13 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B1B12082E for ; Mon, 19 Aug 2019 09:29:12 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id y8so9355207wrn.10 for ; Mon, 19 Aug 2019 09:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PGpLy4IAZNJ9SbBVrwFSn59ybV+MCaj7J3wuvl4ZshE=; b=YGjeWEF+1ZALh4agd7Aki16N9Hp92Vy/UQULGz/GyaFoCVr+68aPDGvQUxVIm+LC4w 57uTZqo4JsfsyAkGKsqllfLh3Rn0nmuLuWBnmErpsHLqfPAOXSHmYfWoZaIspJMx6qju 1IT6ntxnKPJnTYEt76sf38lbGoBGudeR34ClX63AivkUPwz7HFalcRvEa1WEChsD7TBi qOJC9dgfqW3EApS0PWzxccOHo0Z1oe82Mht85jOJ88xTPu67IcraFg0zOtxSSDojP8nI C2kBcZ2FGq2nxXRUB3VGp87NBly6lrn3I/r3OS7D9UG0XZ2kqXVEmsWQgGj6L2mchSPn doSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PGpLy4IAZNJ9SbBVrwFSn59ybV+MCaj7J3wuvl4ZshE=; b=NppGJQhLo6yFzN283Ll+lK0sYKl1YOcqArzKBjMggG8WU/rgNxPWWgP5/L3jF13MCe X23D0iH1CGOX+YqmxE91DT3ltkajLzGejf1dRnZarlKyhhsx12gZirt+SVGBBn2DiDtW 2u5s3Kv/hbIq2wgw7QExBihv6lY+hducf3+gILFthPhKb6CmPYyiZwjqxlBZWDXDjVV3 qV6bUduw4hzEMIA2v/nTHfA17rEMgLG4l4k2/n+3sv4aw81tm7xxom6SLF1GqDhszOEv Ow4rq0plLmDM814u4QTSNopaK+S0iQ3vYbyCcgp8o+XrcN7KjGJonqiRjUqd9v6cWoFW t8hA== X-Gm-Message-State: APjAAAW+DgKKJN9OkvctXwzLjn6M7PlKyg8IAvFi3eGunLBS8C7VhBL3 aQj0rknfSJ3jBuO76rzw/s7zb0+sV49Gusj91MGZcQ== X-Google-Smtp-Source: APXvYqz3e4X2aQzM7NvuxfYcyMZ9XU4u9NPIXLZSK+WELZ/RmCUeLBRa6Q6IO0w/LGP0UC0s3+zszn9W93FktNAJXaE= X-Received: by 2002:a5d:634c:: with SMTP id b12mr27920780wrw.127.1566232150151; Mon, 19 Aug 2019 09:29:10 -0700 (PDT) MIME-Version: 1.0 References: <16840451.Gnsi7N2eSB@linux-9daj> <27027.1565991325@vindemiatrix.encs.concordia.ca> <9323236.5EVOHOzQma@linux-9daj> <24529.1566231048@vindemiatrix.encs.concordia.ca> In-Reply-To: <24529.1566231048@vindemiatrix.encs.concordia.ca> From: Eric Orth Date: Mon, 19 Aug 2019 12:28:58 -0400 Message-ID: To: Anne Bennett Cc: resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2833905907ad659" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 16:29:16 -0000 --000000000000f2833905907ad659 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 19, 2019 at 12:10 PM Anne Bennett wrote: > It seems to me straightforward to use this mechanism to supply > the information *that* a resolver applies filtering, but I don't > see how it could reasonably *describe* the filtering, since > such a description would essentially almost *be* the filtering. > But that could still be very valuable. If (and this is a big if) many recursive resolvers use this mechanism to state whether or not they do significant filtering, then for those that report that they do not, this becomes a strong signal to clients that resolverless DNS will not bypass any filtering. --000000000000f2833905907ad659 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000f2833905907ad659-- From nobody Mon Aug 19 10:07:55 2019 Return-Path: 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 68691120180 for ; Mon, 19 Aug 2019 10:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=JlMiepxl; dkim=pass (1536-bit key) header.d=taugh.com header.b=UdL7gRin 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 n42yaKvo5JcF for ; Mon, 19 Aug 2019 10:07:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1D08712011E for ; Mon, 19 Aug 2019 10:07:51 -0700 (PDT) Received: (qmail 6597 invoked from network); 19 Aug 2019 17:07:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=19c2.5d5ad765.k1908; i=printer-iecc.com@submit.iecc.com; bh=DjjWkeBdGsWo4hU6LvBd0OdxCi4YF57HipUPaK/AD4U=; b=JlMiepxlw8NReiJYMJi0a2Hzvi4N3p5ZgrIaQL1LflDS6JJOsm3B9Ya7XSIJ5vrq4BFRENKHQiJsGk6Y71NY7TGfsUqOphoU4dZUZVNTXW/1m7kFlc/e0eLIQCTdZyVsL+SrRbEAmp4ZeuX8a/OtzrZ+3kTb7p820zy9o+Bru0EES6LKmjVcNNr5V9tcYYfTn1kv7vDy4Ku1TQj0dva+RxSHpk8e8OPyv6AyiDg7cYVauI9/BWlXn6hTT1cEjmpR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=19c2.5d5ad765.k1908; olt=printer-iecc.com@submit.iecc.com; bh=DjjWkeBdGsWo4hU6LvBd0OdxCi4YF57HipUPaK/AD4U=; b=UdL7gRinnewVAm/2W0O+C2VQv9wXHIdixQqhTFpXvnuwoCnUxPJNZc6PDikMlUbuOJjCJHDPnqwDY/YNnxhR9KPZhNrpxU6HeR1rAwssRbsrUHpuQ/h7jFWusjJvYbQ26WXlqXZ2N/DnbsAtjDzbEJ06hR/5SCjJV7iGZzF9meKumizBTGSbFdLd4KJpYHc+7UVPcuQYGkr0RQzgP+kBPHRsc1h+rt3l18zjdM7rBuLtzP90qWjF5AHZFuqLyJcx Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 19 Aug 2019 17:07:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 5AEF588004D; Mon, 19 Aug 2019 13:07:49 -0400 (EDT) Date: 19 Aug 2019 13:07:49 -0400 Message-Id: <20190819170749.5AEF588004D@ary.qy> From: "John Levine" To: resolverless-dns@ietf.org Cc: ericorth@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 17:07:54 -0000 In article you write: >But that could still be very valuable. If (and this is a big if) many >recursive resolvers use this mechanism to state whether or not they do >significant filtering, then for those that report that they do not, this >becomes a strong signal to clients that resolverless DNS will not bypass >any filtering. I'm scratching my head trying to figure out why I would want to configure my DNS resolver to tell random malware and PII stealing apps what my filtering policy is. R's, John From nobody Mon Aug 19 10:17:19 2019 Return-Path: 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 55DFA120043 for ; Mon, 19 Aug 2019 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OW5qswLA; dkim=pass (1536-bit key) header.d=taugh.com header.b=EmyvckJ/ 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 CAlQMzCVntOw for ; Mon, 19 Aug 2019 10:17:16 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6903B12004C for ; Mon, 19 Aug 2019 10:17:16 -0700 (PDT) Received: (qmail 66804 invoked from network); 19 Aug 2019 17:17:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=104ee.5d5ad999.k1908; i=printer-iecc.com@submit.iecc.com; bh=2cz4akSYR/Vn44vLIaJZLoCaW/QPh+pp+yYRWBv7Ifs=; b=OW5qswLAJbrikQGlzod+yyYHwyMqupNpV2i6nzKVp60vDtMODs4H1QvQHunW40BlEEsOP5o832GcMHAtTnoo15OuknL5UFyaA+2PpdG02N4iPzdHLM6PxMsapkiMDPTc6/OodAEtfINMeE/DcUTBbi5FOwwSzZ+ltXA5xqHoB6jK/6wfM8T6Ko0t1q42lsoE3AJtTtZ1wrGox5xjSXW6KDPw7ng4CyETefVMq0SoBlGANhlG+3QGinAHDd5QLLz8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=104ee.5d5ad999.k1908; olt=printer-iecc.com@submit.iecc.com; bh=2cz4akSYR/Vn44vLIaJZLoCaW/QPh+pp+yYRWBv7Ifs=; b=EmyvckJ/cGwNj40z27ZkZAFnIuOhgl21IYVzqE0xABuPZWvsDaie5cXYU5Yc1RhZVZm/s/b+ibM1pNcJJn+0oyqQqUJ1x24sarC24aJBSyRS3AjTVNmwECvUNubfxw/VGJtURdsttAqflW7MvzKLo9YONEiQkwqNpnAcqAIajlxta6LxPNuZ8E6lSRBNNeTiiFZdGwz68YVdV3ilQtZ0LblvBUn8Ww58ns0zbGBXlitwf2XNY/4JJ0SMKG5yvbhP Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 19 Aug 2019 17:17:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 389EF880252; Mon, 19 Aug 2019 13:17:12 -0400 (EDT) Date: 19 Aug 2019 13:17:12 -0400 Message-Id: <20190819171713.389EF880252@ary.qy> From: "John Levine" To: resolverless-dns@ietf.org Cc: sy@informatik.uni-hamburg.de In-Reply-To: <0b18b804-7ebb-bb57-917e-2a9ba5190b2b@informatik.uni-hamburg.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 17:17:17 -0000 In article <0b18b804-7ebb-bb57-917e-2a9ba5190b2b@informatik.uni-hamburg.de> you write: >The authors describe this limitation in their paper. In detail, some >privacy policies are too generic and lack specific information about >what DNS query data was collected, used and stored. Nonetheless, the >authors concluded that the privacy policies of several DNS resolvers >allow using DNS queries to aggregate user data for advertising. Indeed, but since the authors clearly didn't understand what they were talking about, this remains unhelpful. It's hypothetically possible that, say, Google uses query data from 8.8.8.8 to target ads, but in the absence of a lot of other user data like logging in from a Chrome browser it's hard to see how it would be more than a very weak signal in an environment full of strong signals. >indication for the mentioned privacy issue than a description in the >privacy policy. However, I'm not aware of prior empirical research work >in that direction. Neither am I, so I don't understand why anyone makes assertions about what they do. R's, John From nobody Mon Aug 19 12:09:23 2019 Return-Path: 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 49539120814 for ; Mon, 19 Aug 2019 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 rfupw1xpUo6s for ; Mon, 19 Aug 2019 12:09:19 -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 E6725120170 for ; Mon, 19 Aug 2019 12:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id B0AF39F4 for ; Mon, 19 Aug 2019 21:09:16 +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 sTNAeGK3ba6u for ; Mon, 19 Aug 2019 21:09:16 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5C63C.versanet.de [89.245.198.60]) (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 661A49F3 for ; Mon, 19 Aug 2019 21:09:14 +0200 (CEST) To: resolverless-dns@ietf.org References: <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> <6216510.zdPCGfSLMl@linux-9daj> From: Erik Sy 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: <213a986b-479c-3d38-6ec3-cf53264474c2@informatik.uni-hamburg.de> Date: Mon, 19 Aug 2019 21:09:13 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010205010100060307060706" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 19:09:21 -0000 This is a cryptographically signed message in MIME format. --------------ms010205010100060307060706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Ralf, On 8/17/19 23:13, Ralf Weber wrote > The majority of DNS resolvers for end users are still run by ISPs and > Telcos. In that paper you reference the only company that can be seen > as an ISP is Level3, although there resolver in contrast to mosts ISPs > is open. The other are the usual open resolver vendors. So this paper > clearly misses a large part of the resolver population. > > And my experiences with ISPs and Telkos is that they are, probably > because most of them are regulated very sensitive to privacy and > data analysis for marketing and advertising. A lot of them do or > let others do analytics on their data, mostly after being anonymised, > for security purposes, but not more. Nonetheless, there exists empirical evidence that several popular ISPs and Telcos sold data on their customers' online activities to advertising companies [1,2,3]. Thus, it is plausible that these ISPs and Telcos use their DNS resolver to aggregate such user profiles. Note, that features such as Encrypted Server Name Indication (ESNI) for TLS will make the aggregation of such user data based on the analysis of network traffic more difficult. Thus, for ISPs aiming to monitor the users' online activities, the DNS resolver may become an increasingly important source of such user data. Erik 1: http://transition.fcc.gov/Daily_Releases/Daily_Business/2014/db0903/DOC-3= 29127A1.pdf 2: https://www.ftc.gov/system/files/documents/public_comments/2015/09/00008-= 97486.pdf 3: http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.700.4721&rep=3D= rep1&type=3Dpdf --------------ms010205010100060307060706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTkxOTA5MTNaMC8GCSqGSIb3DQEJBDEiBCBxNPJMvIOj vC1/Ewxshx7oaIaQLvFlCETx3xMufY3GkTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQDLB1EI3kCWRNM0esC4A6FHl66ot2fh1XZI3rUJ r3P+rGjaNn4o5pO40GTGjjA6LHiYtfgUT9oFLggSmGreyBvSi9WZyfCcLgTuMNnV87fxaDXm 2H3/PNDHZW0+rSsCXgx5rOay9ZO1KqxZ+1amuqaeGJOgVxzg2eDTsYTCgIFKXE9lXi1j8AhM eY+Amg+G2AZa8/nRB/1dCLxYqYz9ySu7lgNlSUcnTFpD+vIqu0gstlG3UFEO+F+AM5dwJW5U jMmyVCI7i+s3KbQQS2wdlIUanEnmXhWeBhQDR+lchyk/lN/sJ/+tyLkCCg4rR8PBzVUncl3D WJjnpOTyucejo3ENAAAAAAAA --------------ms010205010100060307060706-- From nobody Mon Aug 19 13:25:23 2019 Return-Path: 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 D452D120143 for ; Mon, 19 Aug 2019 13:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 Pb9yMiiZVkJU for ; Mon, 19 Aug 2019 13:25:19 -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 A331F120048 for ; Mon, 19 Aug 2019 13:25:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 5A03CFCD for ; Mon, 19 Aug 2019 22:25:16 +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 TUoCGDVXQqKo for ; Mon, 19 Aug 2019 22:25:15 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5C63C.versanet.de [89.245.198.60]) (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 E0888FCC for ; Mon, 19 Aug 2019 22:25:14 +0200 (CEST) To: resolverless-dns@ietf.org References: <16840451.Gnsi7N2eSB@linux-9daj> <27027.1565991325@vindemiatrix.encs.concordia.ca> <9323236.5EVOHOzQma@linux-9daj> <24529.1566231048@vindemiatrix.encs.concordia.ca> From: Erik Sy 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: Date: Mon, 19 Aug 2019 22:25:13 +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: <24529.1566231048@vindemiatrix.encs.concordia.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000003000305070400040200" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 20:25:21 -0000 This is a cryptographically signed message in MIME format. --------------ms000003000305070400040200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/19/19 18:10, Anne Bennett wrote: > I dispute the idea that DNS over TLS addresses the privacy > problem of the resolver operator having access to all of a > user's DNS queries. > > That being said, I think that stating that traditional DNS has the > "real privacy problem", and implying that resolverless DNS doesn't > suffer from a similar problem, is disingenuous. Ok, I assume we agree on a traditional DNS resolver being able to monitor the user's online activities, right? Resolver-less DNS is different as the web server does not learn anything new about it's users when serving DNS records because it just provides the user with some relevant DNS records. Note, that there does not exist a concept for DNS queries in resolver-less DNS. Furthermore, resolver-less DNS is a decentralized approach where there does not exist a single entity being able to monitor the full scope of the user's online activities. I hope this clarified the privacy difference of the two DNS mechanisms. > > If I ask a question and expect an answer, *someone* has to hear my > question! Who would I rather trust: an ISP whose services I pay for, > or a commercial web site where most likely, I *am* the product?=20 In resolver-less DNS you do not trust retrieved DNS records because you validate these records. In my view, this is a significant benefit of resolver-less DNS as there exist evidence for DNS manipulations conducted by ISPs [1]. Erik 1: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pea= rce.pdf --------------ms000003000305070400040200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTkyMDI1MTNaMC8GCSqGSIb3DQEJBDEiBCAKu/U4QY7Y 2R1d4IRwtd3TBP14DqPfwvVKiMpLgbu7nzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCY6duHXv7RUdhRqKcEJ91gejIt2x23JvMuMRvu mo27PwJbanOx2/pio2zXh8TH1sOYzRswWOwNHzwPFcPz34EeLsh4SMSogriu3PU1ufnOK74k BvZny6q0zTolYMi9lqDrNM753eXBry/wUdriAjjfmm7hBa45TdsRD3s7HEB0HyryAwNEQEAM 8RqaKsSwjBlBFJgwWk4RM3XH+LGyn7mQK56c6MvJO27kJMDhXH5B7cmjEEL0UlutrVPXItpR GBUBDgjILJi1r+yZYWmNY+E6CkL/t7+tCcIyLaEs7FtggZ9IcP/pHy5czrpYf+AC7JjriMkn je7iVYrnHeRK6L+8AAAAAAAA --------------ms000003000305070400040200-- From nobody Mon Aug 19 13:40:07 2019 Return-Path: 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 B0A56120048 for ; Mon, 19 Aug 2019 13:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DD1HtOSG; dkim=pass (1536-bit key) header.d=taugh.com header.b=dn7TNSZG 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 PmO5DM6609nH for ; Mon, 19 Aug 2019 13:39:50 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 121E81208DF for ; Mon, 19 Aug 2019 13:39:49 -0700 (PDT) Received: (qmail 13866 invoked from network); 19 Aug 2019 20:39:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3628.5d5b0914.k1908; i=printer-iecc.com@submit.iecc.com; bh=LWAiSFCWRzLllGWhT5SnCEQ6OekpzrESNbx1/kLZlJc=; b=DD1HtOSGbR/qiTXtBLlnWuUPhLf+/pDotVIt6zDNosXye4K8OYY2FGP2Hh9nGIWggx+EvdFtGzBqRwDeJSkux5+1cJrQ0SCGO4C6G8ewPAVCWPcuJqFNkyF1WWlDDhnJIaXokMyQb1Yg7NA4mFxG+jHGChrjPVqmypY1kEVZyBUWlOvQE5tjgDRtV/zkX9Ly+fPDN4uWncjICoyHm0w6DNdTtZwbIKaf1Xx4xyHofKePCAWXmyoTEopyWoVr5GWT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3628.5d5b0914.k1908; olt=printer-iecc.com@submit.iecc.com; bh=LWAiSFCWRzLllGWhT5SnCEQ6OekpzrESNbx1/kLZlJc=; b=dn7TNSZGKd1tDo7LSnBFSIsFK8554FQwbUiBFEqPMUil+K69uVP9Mq1PeTNRNva9xR2Ft5wv2sHmjjxPhJE8dQSGRbOIpHjY1/B1odFDYg8Nwf7zMMwkJ0HPgPcysgbAXW6/Lh7I+sDvubLLYOF+dEqroA29m7p56X+kt7IafA6SN09seMOsL+UynBu5wC+JzqLm/N94bneecERONd38fNpRZnmk2aIqxiRqnCRXkEBJDdccid1bg5TsIoFPQJSt Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 19 Aug 2019 20:39:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 2BE688829F4; Mon, 19 Aug 2019 16:39:47 -0400 (EDT) Date: 19 Aug 2019 16:39:47 -0400 Message-Id: <20190819203948.2BE688829F4@ary.qy> From: "John Levine" To: resolverless-dns@ietf.org Cc: sy@informatik.uni-hamburg.de In-Reply-To: <213a986b-479c-3d38-6ec3-cf53264474c2@informatik.uni-hamburg.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 20:39:52 -0000 In article <213a986b-479c-3d38-6ec3-cf53264474c2@informatik.uni-hamburg.de> you write: >Nonetheless, there exists empirical evidence that several popular ISPs >and Telcos sold data on their customers' online activities to >advertising companies [1,2,3]. Thus, it is plausible that these ISPs and >Telcos use their DNS resolver to aggregate such user profiles. Actually, no, it's not plausible. The mechanisms described in these papers are nothing like DNS queries. If they could get enough data from DNS queries, why would they bother rewriting HTTP headers? There are issues with DoH but conspiracy theories about implausible data mining of DNS logs really are not helpful. From nobody Mon Aug 19 14:35:46 2019 Return-Path: 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 E43641200EC for ; Mon, 19 Aug 2019 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 kLydFKVDZAla for ; Mon, 19 Aug 2019 14:35:42 -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 60275120048 for ; Mon, 19 Aug 2019 14:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 1A51F47B for ; Mon, 19 Aug 2019 23:35:40 +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 fFpxDFbx15Kt for ; Mon, 19 Aug 2019 23:35:39 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5C63C.versanet.de [89.245.198.60]) (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 16CF247A for ; Mon, 19 Aug 2019 23:35:38 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190819203948.2BE688829F4@ary.qy> From: Erik Sy 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: Date: Mon, 19 Aug 2019 23:35:37 +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: <20190819203948.2BE688829F4@ary.qy> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060809050403010305000907" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 21:35:45 -0000 This is a cryptographically signed message in MIME format. --------------ms060809050403010305000907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/19/19 22:39, John Levine wrote: > In article <213a986b-479c-3d38-6ec3-cf53264474c2@informatik.uni-hamburg= =2Ede> you write: >> Nonetheless, there exists empirical evidence that several popular ISPs= >> and Telcos sold data on their customers' online activities to >> advertising companies [1,2,3]. Thus, it is plausible that these ISPs a= nd >> Telcos use their DNS resolver to aggregate such user profiles. > Actually, no, it's not plausible. The mechanisms described in these > papers are nothing like DNS queries. If they could get enough data > from DNS queries, why would they bother rewriting HTTP headers? They do not use the HTTP header for data collection. Instead, they use the injected HTTP header to=C2=A0 communicate the tracking identifier bet= ween the ISP and the advertising company as shown in this figure: https://jonathanmayer.org/stable/blog_images/verizon_header/verizon_heade= r.png Erik --------------ms060809050403010305000907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MTkyMTM1MzdaMC8GCSqGSIb3DQEJBDEiBCAap9bqzqP5 VNJr6uRz1/bGY6XJCW8WGdmzkJW3QR5YGTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCqXc9eErbyKUqWlgeVedGxs0csoBPnjW1Vya6P J9e4xeDseJisjHJP3mBbmsxma37zihKAlluQtP4f0HJgztIpAc53z0G+KvjvcbQFOcZ7yw+Z SmqMSrRXF3flij6XlH0vGYLvWbMxw0I9QHuQHdL1L5eNXa/AybiG+Jg5EDShNb8rLvhNs83y 1WWw8daX4I3u3RQsVhY8LQzA3NETLWLryt55alBb9VdQ1mxp8EYLtFHqv8D385ch28EzRpMk 8/EJml7ZpsJz4AEnFIpgkcNqaKBwvACXkDk7opTUBBUMfkrmwHTJOZAfXtZA2qZqZoB0Lfvy T5GtMdY176R5d8fxAAAAAAAA --------------ms060809050403010305000907-- From nobody Tue Aug 20 00:03:58 2019 Return-Path: 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 26A29120870 for ; Tue, 20 Aug 2019 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Unx0XtwyeMnd for ; Tue, 20 Aug 2019 00:03:54 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFA81200B3 for ; Tue, 20 Aug 2019 00:03:54 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9CC4E892E8; Tue, 20 Aug 2019 07:03:51 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Cc: Anne Bennett Date: Tue, 20 Aug 2019 07:03:35 +0000 Message-ID: <4328897.o8lPr2jyQz@linux-9daj> Organization: none In-Reply-To: <24529.1566231048@vindemiatrix.encs.concordia.ca> References: <9323236.5EVOHOzQma@linux-9daj> <24529.1566231048@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1947839.oB0V7SU3dg" Content-Transfer-Encoding: 7Bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:03:56 -0000 This is a multi-part message in MIME format. --nextPart1947839.oB0V7SU3dg Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, 19 August 2019 16:10:48 UTC Anne Bennett wrote: ... > AB>> I would think this to be an impossible task; > > PV> this draft in another wg appears to be an attempt at such: > PV> https://datatracker.ietf.org/doc/draft-sah-resolver-information/ > PV> > PV> i don't know if it can meet the "reliably detected" threshold though. > > I took a quick look at the above draft; it specifies a method > for enquiring about "features of a recursive resolver", but > gives no ideas or guidance as to what such features might > consist of, aside from a brief sentence fragment in the > abstract, "such as whether they perform DNSSEC validation or > are available over transports other than what is defined in > RFC 1035". ah. that's my misunderstanding then. i thought "has policy" was one of the assigned indicators. it should be. > It seems to me straightforward to use this mechanism to supply > the information *that* a resolver applies filtering, but I don't > see how it could reasonably *describe* the filtering, since > such a description would essentially almost *be* the filtering. i would not, and we could not, export that policy. it's often proprietary. only the existence of policy, which ought to disable any "app doing DNS" (ADD) from doing DNS, is needed. > I think your polite assumption that it could be possible for > resolverless DNS to respect a network operator's policies for > DNS filtering is, well, polite. ;-) the resolverless people are, like the DoH people, noncriminals with good hearts lacking only some understanding of how criminals use the internet (and the subset of the internet called the web, and the fact that the web is a subset of something). i believe that they will write a spec that recommends respect for the choices made by system and network operators, and i believe that vendors will implement it that way. which means i believe that netflow will continue to be useful in finding malware, because it won't follow the rules. (for a great time, find somebody from sony and ask how much money they would pay in modern dollars to move to the timeline where they knew about north korea the day after they got in.) > .... which brings us to: > > ES>> we talked about possible privacy drawbacks of resolver-less > ES>> DNS. However, did we talk about the privacy risks of using a > ES>> traditional DNS resolver? They can monitor the entire browsing > ES>> activities of a user and present the real privacy problem. > > PV> DoT (RFC 7858) corrects that privacy problem and is being deployed. > > I dispute the idea that DNS over TLS addresses the privacy > problem of the resolver operator having access to all of a > user's DNS queries. i think our ships are passing in the night. "traditional dns resolver" means one you run on your campus, on your LAN, on your hypervisor, on your endpoint. this whole "public DNS" bullpucky is entirely non-traditional. see also: https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/ d-id/1333088[1] > That being said, I think that stating that traditional DNS has the > "real privacy problem", and implying that resolverless DNS doesn't > suffer from a similar problem, is disingenuous. resolverless is questionless. no knowledge of user intent is leaked, only knowledge of user probable next steps. this is an important difference, though it's entirely noncompelling. my network policy is that i be able to monitor and filter DNS. if that means i end up outlawing some web browsers or some web server IP addresses because they want to sneak their DNS translations through as questionless unvalidated unmonitorable unfilterable assertions of pseudo-fact, then that's the war i'll be in. note, i won't choose it, but i won't shirk it either. > If I ask a question and expect an answer, *someone* has to hear my > question! Who would I rather trust: an ISP whose services I pay for, > or a commercial web site where most likely, I *am* the product? again, resolverless means there are no questions. so while it's a huge problem for internet security unless it respects the existence of filtering by local resolvers and unless it respects the same-origin policy, it's a DIFFERENT problem than the one that DoH claims to solve using Big Lie techniques. -- Paul -------- [1] https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/ a/d-id/1333088 --nextPart1947839.oB0V7SU3dg Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Monday, 19 August 2019 16:10:48 UTC Anne Bennett wrote:

...

> AB>> I would think this to be an impossible task;

>

> PV> this draft in another wg appears to be an attempt at such:

> PV> https://datatracker.ietf.org/doc/draft-sah-resolver-information/

> PV>

> PV> i don't know if it can meet the "reliably detected" threshold though.

>

> I took a quick look at the above draft; it specifies a method

> for enquiring about "features of a recursive resolver", but

> gives no ideas or guidance as to what such features might

> consist of, aside from a brief sentence fragment in the

> abstract, "such as whether they perform DNSSEC validation or

> are available over transports other than what is defined in

> RFC 1035".

 

ah. that's my misunderstanding then. i thought "has policy" was one of the assigned indicators. it should be.

 

> It seems to me straightforward to use this mechanism to supply

> the information *that* a resolver applies filtering, but I don't

> see how it could reasonably *describe* the filtering, since

> such a description would essentially almost *be* the filtering.

 

i would not, and we could not, export that policy. it's often proprietary. only the existence of policy, which ought to disable any "app doing DNS" (ADD) from doing DNS, is needed.

 

> I think your polite assumption that it could be possible for

> resolverless DNS to respect a network operator's policies for

> DNS filtering is, well, polite. ;-)

 

the resolverless people are, like the DoH people, noncriminals with good hearts lacking only some understanding of how criminals use the internet (and the subset of the internet called the web, and the fact that the web is a subset of something). i believe that they will write a spec that recommends respect for the choices made by system and network operators, and i believe that vendors will implement it that way.

 

which means i believe that netflow will continue to be useful in finding malware, because it won't follow the rules. (for a great time, find somebody from sony and ask how much money they would pay in modern dollars to move to the timeline where they knew about north korea the day after they got in.)

 

> .... which brings us to:

>

> ES>> we talked about possible privacy drawbacks of resolver-less

> ES>> DNS. However, did we talk about the privacy risks of using a

> ES>> traditional DNS resolver? They can monitor the entire browsing

> ES>> activities of a user and present the real privacy problem.

>

> PV> DoT (RFC 7858) corrects that privacy problem and is being deployed.

>

> I dispute the idea that DNS over TLS addresses the privacy

> problem of the resolver operator having access to all of a

> user's DNS queries.

 

i think our ships are passing in the night. "traditional dns resolver" means one you run on your campus, on your LAN, on your hypervisor, on your endpoint. this whole "public DNS" bullpucky is entirely non-traditional.

 

see also:

 

https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/d-id/1333088

 

> That being said, I think that stating that traditional DNS has the

> "real privacy problem", and implying that resolverless DNS doesn't

> suffer from a similar problem, is disingenuous.

 

resolverless is questionless. no knowledge of user intent is leaked, only knowledge of user probable next steps. this is an important difference, though it's entirely noncompelling. my network policy is that i be able to monitor and filter DNS. if that means i end up outlawing some web browsers or some web server IP addresses because they want to sneak their DNS translations through as questionless unvalidated unmonitorable unfilterable assertions of pseudo-fact, then that's the war i'll be in. note, i won't choose it, but i won't shirk it either.

 

> If I ask a question and expect an answer, *someone* has to hear my

> question! Who would I rather trust: an ISP whose services I pay for,

> or a commercial web site where most likely, I *am* the product?

 

again, resolverless means there are no questions. so while it's a huge problem for internet security unless it respects the existence of filtering by local resolvers and unless it respects the same-origin policy, it's a DIFFERENT problem than the one that DoH claims to solve using Big Lie techniques.

 

--

Paul

--nextPart1947839.oB0V7SU3dg-- From nobody Tue Aug 20 00:05:13 2019 Return-Path: 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 1035F1208C4 for ; Tue, 20 Aug 2019 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IlPTwKZf5B2W for ; Tue, 20 Aug 2019 00:05:05 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFE11208EE for ; Tue, 20 Aug 2019 00:05:05 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B4311892E8; Tue, 20 Aug 2019 07:05:05 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Cc: John Levine , ericorth@google.com Date: Tue, 20 Aug 2019 07:04:50 +0000 Message-ID: <3636215.4jS6DqXcel@linux-9daj> Organization: none In-Reply-To: <20190819170749.5AEF588004D@ary.qy> References: <20190819170749.5AEF588004D@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:05:11 -0000 On Monday, 19 August 2019 17:07:49 UTC John Levine wrote: > In article you write: > >But that could still be very valuable. If (and this is a big if) many > >recursive resolvers use this mechanism to state whether or not they do > >significant filtering, then for those that report that they do not, this > >becomes a strong signal to clients that resolverless DNS will not bypass > >any filtering. > > I'm scratching my head trying to figure out why I would want to > configure my DNS resolver to tell random malware and PII stealing apps > what my filtering policy is. you mustn't, of course. but, anyone who is capable of asking your local RDNS a question should also be capable of finding out, reliably, that there _is_ policy, so that they can shut down any DoH or resolverless logic they may have. -- Paul From nobody Tue Aug 20 00:16:23 2019 Return-Path: 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 81537120870 for ; Tue, 20 Aug 2019 00:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fSoDGhTwQ5yj for ; Tue, 20 Aug 2019 00:16:19 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A141200B3 for ; Tue, 20 Aug 2019 00:16:19 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B8563892E8; Tue, 20 Aug 2019 07:16:19 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Tue, 20 Aug 2019 07:16:03 +0000 Message-ID: <4912129.Q1cc77n183@linux-9daj> Organization: none In-Reply-To: References: <6216510.zdPCGfSLMl@linux-9daj> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart9552664.fpMNh64zhh" Content-Transfer-Encoding: 7Bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:16:22 -0000 This is a multi-part message in MIME format. --nextPart9552664.fpMNh64zhh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, 17 August 2019 19:35:23 UTC Erik Sy wrote: > On 8/17/19 07:39, Paul Vixie wrote: > > On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote: ... > >> Clients using a traditional DNS resolver do not care about a validation > >> of those DNS records. > > > > i have significant evidence to the contrary. > > Can you please share your evidence? i've taken some time to think about this question, because it's as if you've asked a fish, "what is water?" every customer, shareholder, competitor, family member, friend, colleague i have is concerned about bad DNS bindings being consumed by unsuspecting apps. they don't call it by that name, but they think of domain names as "owned by" someone and they want the answers their apps consume to be "authentic" and they know that there's a great risk to life and wealth if this equation doesn't hold. you could if you were interested in learning the extent of how DNS is used and how it is evolving study the deployment of DNSSEC and DANE, both among OS providers, name owners, DNS implementers, and DNS operators. if your mind were open, you could consider the possibility that DNS is larger than the web, is used by many non-web apps, and that any web-only solution is too small to be worth bothering about, and not just a vector by which attackers fool victims. but your mind seems not to be open. in the days since you wrote the above question i've watched you systematically dismiss all arguments that threaten your ideology. i'm making this reply to you because i'll be in hamburg shortly for elbsides and i hope that you will meet me and discuss this in person. but, my hope for this outcome has dimmed with each knee-jerk dismissal that you have offered this thread. > >> In this thread, we talked about possible privacy drawbacks of > >> resolver-less DNS. However, did we talk about the privacy risks of using > >> a traditional DNS resolver? They can monitor the entire browsing > >> activities of a user and present the real privacy problem. > > > > DoT (RFC 7858) corrects that privacy problem and is being deployed. > > The privacy problem is that a significant share of DNS resolvers monitor > the users' online activities, aggregate these data in user profiles and > use these profiles within behavioral advertising or share these user > profiles with other parties. Here [1], you can find a comparative > analysis of public DNS resolver privacy policies substantiating my claims. i prefer the traditional approach where we don't blindly give our data away to google, ibm, cisco, cloudflare, and anyone else who can print a Quad-N t-shirt. run your own RDNS, and use it. for my reasoning, see this article: https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/ d-id/1333088[1] i'll hope to hear contact information for you by the sunday before elbsides. -- Paul -------- [1] https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/ a/d-id/1333088 --nextPart9552664.fpMNh64zhh Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Saturday, 17 August 2019 19:35:23 UTC Erik Sy wrote:

> On 8/17/19 07:39, Paul Vixie wrote:

> > On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote:

...

> >> Clients using a traditional DNS resolver do not care about a validation

> >> of those DNS records.

> >

> > i have significant evidence to the contrary.

>

> Can you please share your evidence?

 

i've taken some time to think about this question, because it's as if you've asked a fish, "what is water?"

 

every customer, shareholder, competitor, family member, friend, colleague i have is concerned about bad DNS bindings being consumed by unsuspecting apps. they don't call it by that name, but they think of domain names as "owned by" someone and they want the answers their apps consume to be "authentic" and they know that there's a great risk to life and wealth if this equation doesn't hold.

 

you could if you were interested in learning the extent of how DNS is used and how it is evolving study the deployment of DNSSEC and DANE, both among OS providers, name owners, DNS implementers, and DNS operators. if your mind were open, you could consider the possibility that DNS is larger than the web, is used by many non-web apps, and that any web-only solution is too small to be worth bothering about, and not just a vector by which attackers fool victims.

 

but your mind seems not to be open. in the days since you wrote the above question i've watched you systematically dismiss all arguments that threaten your ideology. i'm making this reply to you because i'll be in hamburg shortly for elbsides and i hope that you will meet me and discuss this in person. but, my hope for this outcome has dimmed with each knee-jerk dismissal that you have offered this thread.

 

> >> In this thread, we talked about possible privacy drawbacks of

> >> resolver-less DNS. However, did we talk about the privacy risks of using

> >> a traditional DNS resolver? They can monitor the entire browsing

> >> activities of a user and present the real privacy problem.

> >

> > DoT (RFC 7858) corrects that privacy problem and is being deployed.

>

> The privacy problem is that a significant share of DNS resolvers monitor

> the users' online activities, aggregate these data in user profiles and

> use these profiles within behavioral advertising or share these user

> profiles with other parties. Here [1], you can find a comparative

> analysis of public DNS resolver privacy policies substantiating my claims.

 

i prefer the traditional approach where we don't blindly give our data away to google, ibm, cisco, cloudflare, and anyone else who can print a Quad-N t-shirt. run your own RDNS, and use it. for my reasoning, see this article:

 

https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/d-id/1333088

 

i'll hope to hear contact information for you by the sunday before elbsides.

 

--

Paul

--nextPart9552664.fpMNh64zhh-- From nobody Tue Aug 20 01:10:56 2019 Return-Path: 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 6844A120899 for ; Tue, 20 Aug 2019 01:10:54 -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, 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 fGMgxZ_LbgOq for ; Tue, 20 Aug 2019 01:10:52 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 45C7E120147 for ; Tue, 20 Aug 2019 01:10:51 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 457455F42C72; Tue, 20 Aug 2019 10:10:50 +0200 (CEST) Received: from [192.168.2.190] (p54B8ABDF.dip0.t-ipconnect.de [84.184.171.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 5DD675F42A91; Tue, 20 Aug 2019 10:10:48 +0200 (CEST) From: "Ralf Weber" To: "Erik Sy" Cc: resolverless-dns@ietf.org Date: Tue, 20 Aug 2019 10:10:48 +0200 X-Mailer: MailMate (1.12.5r5635) Message-ID: In-Reply-To: References: <20190819203948.2BE688829F4@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 08:10:54 -0000 Moin! On 19 Aug 2019, at 23:35, Erik Sy wrote: > On 8/19/19 22:39, John Levine wrote: >> In article >> <213a986b-479c-3d38-6ec3-cf53264474c2@informatik.uni-hamburg.de> you >> write: >>> Nonetheless, there exists empirical evidence that several popular >>> ISPs >>> and Telcos sold data on their customers' online activities to >>> advertising companies [1,2,3]. Thus, it is plausible that these ISPs >>> and >>> Telcos use their DNS resolver to aggregate such user profiles. >> Actually, no, it's not plausible. The mechanisms described in these >> papers are nothing like DNS queries. If they could get enough data >> from DNS queries, why would they bother rewriting HTTP headers? > They do not use the HTTP header for data collection. Instead, they use > the injected HTTP header to  communicate the tracking identifier > between > the ISP and the advertising company as shown in this figure: > https://jonathanmayer.org/stable/blog_images/verizon_header/verizon_header.png But again it has nothing to do with DNS or selling DNS data. I’ve worked with lots of ISP/Telcos around the globe and most of them were very aware of the privacy aspect of DNS data and treated it with great care. So long -Ralf --- Ralf Weber From nobody Tue Aug 20 03:23:29 2019 Return-Path: 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 4A0D012004A for ; Tue, 20 Aug 2019 03:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 (2048-bit key) header.d=open-xchange.com 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 9Cdfgvk3XmnV for ; Tue, 20 Aug 2019 03:23:25 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 7DDFE12003E for ; Tue, 20 Aug 2019 03:23:25 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8DEE86A290 for ; Tue, 20 Aug 2019 12:23:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566296601; bh=WXu+6VcdIOnDpMetW4PK/UDuPcfwj77vmu/11lKM9KA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=7fxyw/4zOU2U34V55h/ZKu1iaz5gOsTzyNfiBqzh7rMcJ3aGrh7y58hysKEaTlunp PkGP+ZWbsr5WLWCzKxkEAEAwBaIQSXxQGJf7ELk70FwHPS0cV3xT0lhWhmAi0v/Bg7 hnhrdprDhKQsj/MNLJoK/sbiGswTPm2QfU9Hx1PD7cRJ7tXG4DPRWf1D2RMkjC+zQK yFJDzkJMwX9USFwQBrOb4A8rPev86/VAORKmLHuTs5sSUDYYKr5qOSWMt+dPdTPabn Qhj9mRf56rzpG6CqsQdSxZit8m++EjbGb7vD1yldobXHSag5AhAAmj4t6o8YDNSI0O Ht2uw2K1yNnzg== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 81C623C0434 for ; Tue, 20 Aug 2019 12:23:21 +0200 (CEST) Date: Tue, 20 Aug 2019 12:23:21 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: resolverless-dns@ietf.org Message-ID: <1120786282.10734.1566296601469@appsuite-gw2.open-xchange.com> In-Reply-To: <20190819170749.5AEF588004D@ary.qy> References: <20190819170749.5AEF588004D@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 10:23:27 -0000 > Il 19 agosto 2019 19:07 John Levine ha scritto: > > In article you write: > >But that could still be very valuable. If (and this is a big if) many > >recursive resolvers use this mechanism to state whether or not they do > >significant filtering, then for those that report that they do not, this > >becomes a strong signal to clients that resolverless DNS will not bypass > >any filtering. > > I'm scratching my head trying to figure out why I would want to > configure my DNS resolver to tell random malware and PII stealing apps > what my filtering policy is. Also, when filtering is applied for human dignity reasons (e.g. to block racist content, terrorist websites, child porn etc.) you explicitly do not want to publish the list of blocked destinations, as it would be an easy directory for wannabe racists/terrorists/pedophiles... -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Aug 20 10:24:54 2019 Return-Path: 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 64DE812095B for ; Tue, 20 Aug 2019 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 D0r5fp_tRlsn for ; Tue, 20 Aug 2019 10:24:46 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6544A120990 for ; Tue, 20 Aug 2019 10:24:46 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192] port 12940) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id x7KHOhOl010770 for ; Tue, 20 Aug 2019 13:24:43 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.7/8.14.7/Submit) with ESMTP id x7KHOfdc025919 for ; Tue, 20 Aug 2019 13:24:43 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: resolverless-dns@ietf.org References: <9323236.5EVOHOzQma@linux-9daj> <24529.1566231048@vindemiatrix.encs.concordia.ca> <4328897.o8lPr2jyQz@linux-9daj> In-Reply-To: <4328897.o8lPr2jyQz@linux-9daj> X-In-Reply-To: Your message of Tue, 20 Aug 2019 07:03:35 -0000 From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 20 Aug 2019 13:24:41 -0400 Message-ID: <25918.1566321881@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2019-08-20 13:24:43 EDT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:24:52 -0000 PV>>> https://datatracker.ietf.org/doc/draft-sah-resolver-information/ AB>> I took a quick look at the above draft; it specifies a method AB>> for enquiring about "features of a recursive resolver", but AB>> gives no ideas or guidance as to what such features might AB>> consist of, aside from a brief sentence fragment in the AB>> abstract, "such as whether they perform DNSSEC validation or AB>> are available over transports other than what is defined in AB>> RFC 1035". PV> ah. that's my misunderstanding then. i thought "has policy" was PV> one of the assigned indicators. it should be. It may well become one; the draft states that "IANA will create a new registry titled "DNS Resolver Information" that will contain definitions of the names that can be used with the protocols defined in this document", but since such a registry is not implemented yet, the reader of the draft can't assume what's intended. Likely you've seen another document or followed another discussion that mentioned it. AB>> It seems to me straightforward to use this mechanism to supply AB>> the information *that* a resolver applies filtering, but I don't AB>> see how it could reasonably *describe* the filtering, since AB>> such a description would essentially almost *be* the filtering. PV> i would not, and we could not, export that policy. We're on the same page there! ES>>>> we talked about possible privacy drawbacks of resolver-less ES>>>> DNS. However, did we talk about the privacy risks of using a ES>>>> traditional DNS resolver? They can monitor the entire browsing ES>>>> activities of a user and present the real privacy problem. PV>>> DoT (RFC 7858) corrects that privacy problem and is being deployed. AB>> I dispute the idea that DNS over TLS addresses the privacy AB>> problem of the resolver operator having access to all of a AB>> user's DNS queries. PV> i think our ships are passing in the night. Quite possibly, or mine may have sprung a leak. ;-) PV> "traditional dns resolver" means one you run on your campus, PV> on your LAN, on your hypervisor, on your endpoint. this whole PV> "public DNS" bullpucky is entirely non-traditional. Ah, I was assuming that "traditional" DNS resolution was the mechanism of UDP or TCP queries to port 53 (or, now, 853), no matter who was running the resolver. I don't have stats on devices on the Internet, but I suspect that the number of DNS clients on networks run professionally, with local resolvers, is, at this point, probably small compared to the number of cellphones, laptops, home systems, and IoT devices. Ideally, these would all would use the ISP's resolvers, but if people are connecting to untrusted networks (e.g. wireless at the airport or coffee shop), I can well imagine why using one of the "public" resolvers might be considered safer, though if DNSSEC validation is used, a hostile or compromised ISP might matter less. PV> resolverless is questionless. no knowledge of user intent is PV> leaked, only knowledge of user probable next steps. this is PV> an important difference, Thank you for setting me straight on that; I was indeed thinking of DoH. ES> Ok, I assume we agree on a traditional DNS resolver being able ES> to monitor the user's online activities, right? If here you define "traditional DNS resolver" as the port 53 (or 853) answerer of questions, then, sort of - that is, most of the user's online activities will be based on the resolution of hostnames to IP addresses, and the hostname queries will give the resolver a pretty good idea of the sites of interest to the user. But... the ISP can already do traffic analysis, based on the endpoints of the TCP/IP connections (not to mention sniff the traffic if it is not encrypted), so if the user is using the ISP's resolver, there's no *additional* privacy concern there, I think. If you're considering that some people use the "big public resolvers", then sure, those sites could be acquiring information which a user would prefer to keep private. It's rather tempting to say "so don't do that" (that is, don't use the big public resolvers), though. I'm still not convinced that a whole new DNS mechanism is a step in the right direction; it seems to me like just one more attack surface to have to monitor and protect. ES> Furthermore, resolver-less DNS is a decentralized approach ES> where there does not exist a single entity being able to monitor ES> the full scope of the user's online activities. The ISP will always be able to do that, even if only traffic analysis. ES> In resolver-less DNS you do not trust retrieved DNS records ES> because you validate these records. At this point, you should probably tell me to Read The Fine Paper, but I immediately wonder: *how* does the client validate the records? I suppose the server may be sending all the DNSSEC information. If so, though, your scheme still cuts off my ability, as a network admin, to use DNS resolution to impose policies to protect my users from malware (for example). Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Aug 20 12:08:32 2019 Return-Path: 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 87E5F120833 for ; Tue, 20 Aug 2019 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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 eE-It5YPf1a7 for ; Tue, 20 Aug 2019 12:08:26 -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 94C13120805 for ; Tue, 20 Aug 2019 12:08:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 5B0C6B3F for ; Tue, 20 Aug 2019 21:08:24 +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 YkU6xeG5hVNH for ; Tue, 20 Aug 2019 21:08:23 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB622.versanet.de [87.123.182.34]) (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 6C8B1B3E for ; Tue, 20 Aug 2019 21:08:20 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190819170749.5AEF588004D@ary.qy> <1120786282.10734.1566296601469@appsuite-gw2.open-xchange.com> From: Erik Sy 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: <13289521-3977-886e-ddfa-d7fc4728912e@informatik.uni-hamburg.de> Date: Tue, 20 Aug 2019 21:08:19 +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: <1120786282.10734.1566296601469@appsuite-gw2.open-xchange.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030707010402040607060809" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:08:29 -0000 This is a cryptographically signed message in MIME format. --------------ms030707010402040607060809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/20/19 12:23, Vittorio Bertola wrote: > Also, when filtering is applied for human dignity reasons (e.g. to bloc= k racist content, terrorist websites, child porn etc.) you explicitly do = not want to publish the list of blocked destinations, as it would be an e= asy directory for wannabe racists/terrorists/pedophiles... > The better way to handle illegal content online is the notice and takedown approach because the provider will delete that specific content and it becomes inaccessible to all internet user. There exist organisations such as [1] and [2] where it is easy to report illegal content and they do the remaining work such as informing providers and instigating a criminal prosecution. This notice and takedown achieves to delete about 60% of the reported illegal content within the first three days [3]. Erik 1: https://www.cybertip.ca 2: http://88.208.218.79/gns/internet-concerns/overview-of-the-problem/illega= l-content.aspx 3: http://88.208.218.79/Libraries/2017_stats/notice-and-takedown.sflb.ash= x --------------ms030707010402040607060809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjAxOTA4MTlaMC8GCSqGSIb3DQEJBDEiBCDTN0XYcq8Y LW4HJkRjm1EigBWTDYgalpqNYk1eVsiPwDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAzlICCLp31erMf0AeAcprq8IyPBAQfm8hBZWsu 8lkpCPerpQYS8p+Re3h74sTMIYHWHcW+psIK3E7eeBMCEbIYNuuUB7A8TIcx0iI5+Sap6Cq9 ET9JSuXyRN+VZoUzppiMZ08i+XHnmARIuvwKIAnAsOrE795bamef6fQCGbYUxH2AyfbJ1TkY FZ164GeUFQqcnLG5LCrFADZDbNFTxKRLKPGp/hZyU7QKjYdvv5bGuYdAD6wbIgEhApfqtpFP P1tgUFa/V9Jq1eyT5q6j8fS496t+V4GqeshIQoWzuoVPL06Pf3dhBdex0gl4obbDdWm841br xqHmEcEMB1ytP9R1AAAAAAAA --------------ms030707010402040607060809-- From nobody Tue Aug 20 12:30:16 2019 Return-Path: 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 5E23512084A for ; Tue, 20 Aug 2019 12:30:14 -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 GurTM0eFbgFp for ; Tue, 20 Aug 2019 12:30:12 -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 484AE120111 for ; Tue, 20 Aug 2019 12:30:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id CA24FC00 for ; Tue, 20 Aug 2019 21:30:10 +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 yK0eD5i4IuTF for ; Tue, 20 Aug 2019 21:30:10 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB622.versanet.de [87.123.182.34]) (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 E1873BFF for ; Tue, 20 Aug 2019 21:30:09 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190819203948.2BE688829F4@ary.qy> From: Erik Sy 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: <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> Date: Tue, 20 Aug 2019 21:30:08 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050002080609060106050608" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:30:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050002080609060106050608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/20/19 10:10, Ralf Weber wrote: >>>> Nonetheless, there exists empirical evidence that several popular IS= Ps >>>> and Telcos sold data on their customers' online activities to >>>> advertising companies [1,2,3]. Thus, it is plausible that these >>>> ISPs and >>>> Telcos use their DNS resolver to aggregate such user profiles. >>> Actually, no, it's not plausible.=C2=A0 The mechanisms described in t= hese >>> papers are nothing like DNS queries.=C2=A0 If they could get enough d= ata >>> from DNS queries, why would they bother rewriting HTTP headers? >> They do not use the HTTP header for data collection. Instead, they use= >> the injected HTTP header to=C2=A0 communicate the tracking identifier = between >> the ISP and the advertising company as shown in this figure: >> https://jonathanmayer.org/stable/blog_images/verizon_header/verizon_he= ader.png >> > But again it has nothing to do with DNS or selling DNS data. I=E2=80=99= ve > worked with > lots of ISP/Telcos around the globe and most of them were very aware > of the > privacy aspect of DNS data and treated it with great care. > Ok, as a matter of fact we have evidence that some ISPs collected data on their customers' private online activities with the intention to sell this information to advertising companies. Your standpoint is, that this has nothing to do with the ISP's DNS resolver or selling DNS data. I have no explanation why an ISP should apply better privacy protections to their customers DNS data compared to the customers network traffic because both enable a significant monitoring of the users' online activities. Do you have an explanation for this? Erik=C2=A0 --------------ms050002080609060106050608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjAxOTMwMDhaMC8GCSqGSIb3DQEJBDEiBCCfXTGkl9UG bBROhUlvDds9D/F8zGEh9jJfF6/oAoc/oDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQA2pzEcG0kcH8bmUOMuEMwwpJBRoKiSwZFftCDJ t6aJ+TFFbezTk/OKHOTpAHPyOBMHdxlGJ2ggehO2JM46PWRiR39042WWfMB44H4jscZML2Vf knhMh/f2XeedmXExFRUCqambk5MGvyCB7Oze0AR/j8sRqHM+7IdQ1DmLdUIBMUWpNn7HV64w BIRXZaHJIn9eYfFZIxUruY1emlWoF/R2w/uHy1QdwuIiLcuNYm0luEgfTLRNLg+tM/odk4t6 QDG5sKPlD+92XjEEHkd4+h+kVEg2iUC7C0gdWY5SsH+kSb1xFZgowaUB7eFnfDSvKFA7kz+L RCLJkvZl7u2L94vKAAAAAAAA --------------ms050002080609060106050608-- From nobody Tue Aug 20 14:10:10 2019 Return-Path: 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 B74991200A3 for ; Tue, 20 Aug 2019 14:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 Q-UCI5jpi6ke for ; Tue, 20 Aug 2019 14:10:05 -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 96780120059 for ; Tue, 20 Aug 2019 14:10:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id DC0A747C for ; Tue, 20 Aug 2019 23:10:03 +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 xAwsJdlG50ry for ; Tue, 20 Aug 2019 23:10:03 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB622.versanet.de [87.123.182.34]) (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 EC51447B for ; Tue, 20 Aug 2019 23:10:02 +0200 (CEST) To: resolverless-dns@ietf.org References: <6216510.zdPCGfSLMl@linux-9daj> <4912129.Q1cc77n183@linux-9daj> From: Erik Sy 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: Date: Tue, 20 Aug 2019 23:10:01 +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: <4912129.Q1cc77n183@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040100030301010106030409" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 21:10:09 -0000 This is a cryptographically signed message in MIME format. --------------ms040100030301010106030409 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/20/19 09:16, Paul Vixie wrote: > > > >> Clients using a traditional DNS resolver do not care about a > validation > > > >> of those DNS records. > > > > > > > > i have significant evidence to the contrary. > > > > > > Can you please share your evidence? > > =A0 > > i've taken some time to think about this question, because it's as if > you've asked a fish, "what is water?" > > =A0 > > every customer, shareholder, competitor, family member, friend, > colleague i have is concerned about bad DNS bindings being consumed by > unsuspecting apps. they don't call it by that name, but they think of > domain names as "owned by" someone and they want the answers their > apps consume to be "authentic" and they know that there's a great risk > to life and wealth if this equation doesn't hold. > > =A0 > > you could if you were interested in learning the extent of how DNS is > used and how it is evolving study the deployment of DNSSEC and DANE, > both among OS providers, name owners, DNS implementers, and DNS > operators. if your mind were open, you could consider the possibility > that DNS is larger than the web, is used by many non-web apps, and > that any web-only solution is too small to be worth bothering about, > and not just a vector by which attackers fool victims. > I'm aware of DNSSEC and DANE and their deployment issues. In total, I'm still missing the evidence you claimed to have on clients validating DNS records retrieved from traditional DNS resolver. I assume that by referring to DNSSEC and DANE, you do not want to claim that some popular client software is strictly enforcing a validation of DNS records using DNSSEC and DANE, right? > > but your mind seems not to be open. in the days since you wrote the > above question i've watched you systematically dismiss all arguments > that threaten your ideology. i'm making this reply to you because i'll > be in hamburg shortly for elbsides and i hope that you will meet me > and discuss this in person. but, my hope for this outcome has dimmed > with each knee-jerk dismissal that you have offered this thread. > You may have noticed that I'm also giving a talk at the elbsides shorly after yours. Thus, it will be easy for us to meet each other there. Erik --------------ms040100030301010106030409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjAyMTEwMDFaMC8GCSqGSIb3DQEJBDEiBCA4zrMMz+eB dkg5ZNvgKTF90Az4aS2IFlVnPPfwFryP5DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBlKAYgRbdBgjXOluQZAgt8kt2NlEwEpkakxDW6 1okgM0QZtkzwASNQPJ3xEyJRvXLD8sHBSligpwznACH0Oib24jpyr2ZU/T4CUPY53XjjkIeZ rixYEv8s8jbUdCWvHTI1x+M3h0pQbgNw7m1Agh9TS+XfwMegXSqTgMheLslYcOKNYc4rHGCn 9r4ZKHVcFQyAP5tX/FnePR5imjpiwi7upbtIBr/d3kiIC9AH5H6YUFwcT6v8fLDaqgtxar0w HQs0kdut/iRhYE5ir6eXyZ5WSLLEW3ikFg4N4r1Us6rTsSWOgzFJAt/Lro8+xXKV3XeofUW1 xwGkzvLe6s+tYjfPAAAAAAAA --------------ms040100030301010106030409-- From nobody Tue Aug 20 14:12:58 2019 Return-Path: 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 8F0DA1200A3 for ; Tue, 20 Aug 2019 14:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 dueEc2RP-AoN for ; Tue, 20 Aug 2019 14:12:54 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1230A120059 for ; Tue, 20 Aug 2019 14:12:54 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E78B6892E8; Tue, 20 Aug 2019 21:12:53 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Tue, 20 Aug 2019 21:12:53 +0000 Message-ID: <4568720.uvMTqBdgP4@linux-9daj> Organization: none In-Reply-To: References: <4912129.Q1cc77n183@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 21:12:56 -0000 On Tuesday, 20 August 2019 21:10:01 UTC Erik Sy wrote: > ... > I'm aware of DNSSEC and DANE and their deployment issues. In total, I'm > still missing the evidence you claimed to have on clients validating DNS > records retrieved from traditional DNS resolver. that's moving of goalposts; i won't follow. > I assume that by > referring to DNSSEC and DANE, you do not want to claim that some popular > client software is strictly enforcing a validation of DNS records using > DNSSEC and DANE, right? caching resolvers everywhere, do this. the economy depends on them doing so. if RDNS isn't client software from your point of view, you'll dismiss these assertions. > ... > > You may have noticed that I'm also giving a talk at the elbsides shorly > after yours. Thus, it will be easy for us to meet each other there. that's great! -- Paul From nobody Wed Aug 21 00:38:01 2019 Return-Path: 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 EA0E91208F5 for ; Wed, 21 Aug 2019 00:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Qlmu89dp_fE1 for ; Wed, 21 Aug 2019 00:37:54 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD21208D6 for ; Wed, 21 Aug 2019 00:37:54 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 3904A5F42D3F; Wed, 21 Aug 2019 09:37:53 +0200 (CEST) Received: from [192.168.2.190] (p54B8ABDF.dip0.t-ipconnect.de [84.184.171.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 596FB5F42337; Wed, 21 Aug 2019 09:37:51 +0200 (CEST) From: "Ralf Weber" To: "Erik Sy" Cc: resolverless-dns@ietf.org Date: Wed, 21 Aug 2019 09:37:50 +0200 X-Mailer: MailMate (1.12.5r5635) Message-ID: <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> In-Reply-To: <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> References: <20190819203948.2BE688829F4@ary.qy> <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 07:38:00 -0000 Moin! On 20 Aug 2019, at 21:30, Erik Sy wrote: > Ok, as a matter of fact we have evidence that some ISPs collected data > on their customers' private online activities with the intention to sell > this information to advertising companies. They were also fined and had to stop it. Part of the reason here is probably because unlike web companies ISP and Telcos are regulated in most parts of the world. > Your standpoint is, that this > has nothing to do with the ISP's DNS resolver or selling DNS data. Yes because I have not seen evidence and certainly not broad evidence needed to call this a common practice which a lot of people do. I’ve seen lots of evidence of people abusing HTTP (the once you cite being one) to invade user privacy. Thus I want my name resolution to go to my ISP and not to some web server operator I have no relationship with. > I have no explanation why an ISP should apply better privacy protections > to their customers DNS data compared to the customers network traffic > because both enable a significant monitoring of the users' online > activities. Do you have an explanation for this? Yes. ISP/Telcos are usually big organisations. DNS mostly is seen as a network function and thus is within some kind of engineering department. Engineers have a different mindset on data then say people working in a marketing department, which usually is where these advertising programs originate. So long -Ralf --- Ralf Weber From nobody Wed Aug 21 01:25:28 2019 Return-Path: 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 A452812083E for ; Wed, 21 Aug 2019 01:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 (2048-bit key) header.d=open-xchange.com 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 hmiHWzmtcWkE for ; Wed, 21 Aug 2019 01:25:25 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 1DEBF12081F for ; Wed, 21 Aug 2019 01:25:25 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 737EB6A268; Wed, 21 Aug 2019 10:25:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566375919; bh=tTZO/hE5PosSNvXC/yXY19gVSLU3ppn1dyJ44vCDlbw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=QQDZeqp7gsXnLpzn5si0/qhQ4WHrd3BlcddYMPCX3KW3i+GRGRvTck0FpNwwHd9eR WNdHqywR96NgAZQVtdYPQQJ023zaQ5VX21fAN35kB9fh5ayn2aWyLIFi3it1gRWxvI eiTQPSV5SVKhRhpvU6efJFdRhnRwL4qdCaHBn9eFLhkcZLkwgNSFMU8Ae1cvXidfxM iY4Fjwn+HdWv3HQ0IVfrzd/dN71mo8u66PHFChfCb3uBEYCMxWroIXZR2B930jVOl8 l1k4RwKdmmrOMWPNwiz8wE6lo7hL4UYq3NlGZQag6Qhl3xtYQEJtcbOoD7QyOTRz2Y i54B57CHzSq1Q== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 676CB3C0B3F; Wed, 21 Aug 2019 10:25:19 +0200 (CEST) Date: Wed, 21 Aug 2019 10:25:19 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Ralf Weber , Erik Sy Cc: resolverless-dns@ietf.org Message-ID: <308719327.4183.1566375919372@appsuite-gw1.open-xchange.com> In-Reply-To: <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> References: <20190819203948.2BE688829F4@ary.qy> <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 08:25:27 -0000 > Il 21 agosto 2019 09:37 Ralf Weber ha scritto: > > On 20 Aug 2019, at 21:30, Erik Sy wrote: > > I have no explanation why an ISP should apply better privacy protections > > to their customers DNS data compared to the customers network traffic > > because both enable a significant monitoring of the users' online > > activities. Do you have an explanation for this? > Yes. ISP/Telcos are usually big organisations. DNS mostly is seen as > a network function and thus is within some kind of engineering department. > Engineers have a different mindset on data then say people working in a > marketing department, which usually is where these advertising programs > originate. Also, an ISP's business is to sell Internet access and other connectivity services, which means that if they alienate their users by violating their privacy, users will go elsewhere and they will make less money; sure, an ISP may be tempted to increase their revenues by also monetizing user information, but definitely not up to the point of threatening their core business. On the other hand, the business model of Google, Facebook and most of the web companies is surveillance capitalism: personal information is the raw material for their products, and the more they find ways to invade the privacy of their users, the more money they make. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Aug 21 01:42:41 2019 Return-Path: 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 AACB51201E4 for ; Wed, 21 Aug 2019 01:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 (2048-bit key) header.d=open-xchange.com 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 AfdavG3jV1ke for ; Wed, 21 Aug 2019 01:42:38 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 D794F120122 for ; Wed, 21 Aug 2019 01:42:37 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id EBF7F6A27D; Wed, 21 Aug 2019 10:42:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566376956; bh=BZtogblYPiTEd/GqG/xxx7a9vQru3vBTg6W+5jJ0Dss=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=a+T5lClSsGaS16hOk3ea3sPsJV08ezdCoW9QNXeivcDN05trWuTnoZJrNAUxIDi18 SIfHzsAb4ZZIky4PbECeHvBjnsO/ySM+Zez7FkiRPCyX6F4dO/AQQTikJEo721Cfcl h0tMImjfn2wau6DKrhRj5R9EGRx8mrd164UTfP97mKqS1aL8AuBwrw+Vtgfu0IQkEO rJ/Hbpc1BtLnzkYVlGD88PwD80+jZCUKpWjw7yIAtiU62bbdCTFpLvuSSPTTa1DxFV q56n4GPcrOv2IJDzKyN7aXvTvCTazX0GiYEQwPwiYaviJRR1yvceWVIwoT0uDAgNeE VKDNP92qiyjtA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id D343E3C0B05; Wed, 21 Aug 2019 10:42:35 +0200 (CEST) Date: Wed, 21 Aug 2019 10:42:35 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org Message-ID: <1510635197.4293.1566376955811@appsuite-gw1.open-xchange.com> In-Reply-To: <13289521-3977-886e-ddfa-d7fc4728912e@informatik.uni-hamburg.de> References: <20190819170749.5AEF588004D@ary.qy> <1120786282.10734.1566296601469@appsuite-gw2.open-xchange.com> <13289521-3977-886e-ddfa-d7fc4728912e@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 08:42:40 -0000 > Il 20 agosto 2019 21:08 Erik Sy ha scritto: > > On 8/20/19 12:23, Vittorio Bertola wrote: > > Also, when filtering is applied for human dignity reasons (e.g. to block racist content, terrorist websites, child porn etc.) you explicitly do not want to publish the list of blocked destinations, as it would be an easy directory for wannabe racists/terrorists/pedophiles... > > > The better way to handle illegal content online is the notice and > takedown approach Unfortunately, the notice and takedown approach works only if the content is hosted within the country. It just takes a credit card for the criminal to buy hosting somewhere else on the planet, and at that point, if you are lucky the international takedown process takes a long time, and if you are unlucky the criminal will find a country which doesn't care (there's a big one just east of the EU) or even a country in which that specific content is legal. For example, the biggest chunk of the mandatory DNS filtering list for ISPs in Italy is made of illegal gambling websites - foreign gambling websites that did not pay the compulsory license and taxes to the Italian government and did not accept to be audited to ensure that the games are not rigged and that they do not do money laundering for the mafia (which is the real business for many of them). These websites might just be legal where they are incorporated, which might be as near as Malta; but other countries still need a way to enforce their own policies when these websites approach their citizens, and their only leverage is the ability to make them unreachable from within the country. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Aug 21 06:04:20 2019 Return-Path: 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 41C8912092A for ; Wed, 21 Aug 2019 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 GzBjM3rn4oCJ for ; Wed, 21 Aug 2019 06:04:16 -0700 (PDT) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32C8120911 for ; Wed, 21 Aug 2019 06:04:16 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id y26so2904638qto.4 for ; Wed, 21 Aug 2019 06:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9JM4L2XQdlZ5Qj4+vzF8LuHZxuxz8Ich7kPpyFFnrd8=; b=X4t7ZOl9RC8C/id8pGBKP+l0tGEcieCDPkmGZfRDk0sG3xgDqv9ddqFSqTrCbLZIeM YjgICJvo4dg6k584NCubDoH0lKPIFGf9kejrq2Ewxv0FCLxwIeHohKR8/I9AfZYdY0BA pClY8FIggKNDi4yuYtirpGQ0H8AaK+uYud+UI0xLQwbFui8j59SFWikRB8OoaVH5/lz1 XZx3KEFPZIQklrLvC9q63Y4GlVWZ9DzuxXRHKTg/MlHvqltdtFA2Ehy5exVuhzylCkO/ h/5xL/7sIIpd8MruYALEhFeovElG3ey+53LvrZAMaDHvo7KuGZeZNe+1KGfQ3exOCWYz pBhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9JM4L2XQdlZ5Qj4+vzF8LuHZxuxz8Ich7kPpyFFnrd8=; b=SW0cpcvX29egbwuk+8KeT3Qd/0rvS86zOrmFSQZsBjTGv8yB+fU5W+hkLSVLo9LfE2 c/r2uq30cVfb5H3c8B1gK4MI12WhbzxPfNTx4LQ/ha6hFaxhARXVVQCwIrwM87iThIHG mEWXDQAGiP5HEuaqsbzwXLv7aJ7t3v0kACpL19RfvVLem88ZiI2Rt7V1XfAc0GO7VbiB IPYddg1DWy0Q/yOLtOxz+C+Xh7ktwlubbL6RaSXqueLnJeN7+apff6J/TxJ3ShJDKhpg fRSxba8oh15QDxakgMWerxK7aNqlRmCurM/o9/8Bbd2pqpSw3UQ4Am4lr5AqMhr/68Dw 8wHw== X-Gm-Message-State: APjAAAUXWQUnOxhyI/jLKRz5lZnpTr8q50CITf79n6c93N0g1+mtTv5m X0ab+Qf9dOV6A+0yqoTFWWDB2g== X-Google-Smtp-Source: APXvYqxPjRbj3PRaW6hhhF7aIkN92vZ2Xezlx07DtweUlSrHQWhxM9jDjnk4ljsEhbwcid5JN2tg8Q== X-Received: by 2002:a0c:ea4f:: with SMTP id u15mr16088248qvp.115.1566392655856; Wed, 21 Aug 2019 06:04:15 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:ed6b:91fc:f80e:f44a? ([2001:470:c1a2:1:ed6b:91fc:f80e:f44a]) by smtp.gmail.com with ESMTPSA id t2sm9565018qtq.73.2019.08.21.06.04.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 06:04:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9FCB8D31-A7B7-47C2-B515-E1991F57DDAA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ted Lemon X-Priority: 3 In-Reply-To: <308719327.4183.1566375919372@appsuite-gw1.open-xchange.com> Date: Wed, 21 Aug 2019 06:04:13 -0700 Cc: Ralf Weber , Erik Sy , resolverless-dns@ietf.org Message-Id: <2070DE2D-C28F-4B5A-BC06-E14A6CB834E6@fugue.com> References: <20190819203948.2BE688829F4@ary.qy> <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> <308719327.4183.1566375919372@appsuite-gw1.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:04:18 -0000 --Apple-Mail=_9FCB8D31-A7B7-47C2-B515-E1991F57DDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 21, 2019, at 1:25 AM, Vittorio Bertola = wrote: > which means that if they alienate their users by violating their = privacy, users will go elsewhere You are lucky to live in a place where all the telcos do not have = monopolies. I have no choice of ISP: I either take the one I have, or = I live my life offline. --Apple-Mail=_9FCB8D31-A7B7-47C2-B515-E1991F57DDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Aug 21, 2019, at 1:25 AM, Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:
which means = that if they alienate their users by violating their privacy, users will = go elsewhere

You are lucky to live in a place where all the telcos do not = have monopolies.   I have no choice of ISP: I either take the one I = have, or I live my life offline.

= --Apple-Mail=_9FCB8D31-A7B7-47C2-B515-E1991F57DDAA-- From nobody Wed Aug 21 12:54:13 2019 Return-Path: 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 7ABD11209BC for ; Wed, 21 Aug 2019 12:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 orxLWlLj9m3N for ; Wed, 21 Aug 2019 12:54:01 -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 087051209B9 for ; Wed, 21 Aug 2019 12:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 3EE801D0 for ; Wed, 21 Aug 2019 21:53:58 +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 5L4Xt67yNTxo for ; Wed, 21 Aug 2019 21:53:57 +0200 (CEST) Received: from users-MBP.fritz.box (mue-88-130-89-191.dsl.tropolys.de [88.130.89.191]) (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 1F1BC1CF for ; Wed, 21 Aug 2019 21:53:56 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190819203948.2BE688829F4@ary.qy> <299fda32-c699-cd00-8108-696bc3c6c28b@informatik.uni-hamburg.de> <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> From: Erik Sy 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: <7ad31866-66c8-7f50-50b4-775993ae1267@informatik.uni-hamburg.de> Date: Wed, 21 Aug 2019 21:53:55 +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: <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050803060703050100030401" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 19:54:04 -0000 This is a cryptographically signed message in MIME format. --------------ms050803060703050100030401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/21/19 09:37, Ralf Weber wrote: >> Ok, as a matter of fact we have evidence that some ISPs collected data= >> on their customers' private online activities with the intention to se= ll >> this information to advertising companies. > They were also fined and had to stop it. Part of the reason here is > probably because unlike web companies ISP and Telcos are regulated in > most parts of the world. Yes, ISPs and Telcos are regulated and they broke the law and collected data on their customers' private online activities. In case these companies break the law again, private user data are still pretty unprotected. >> I have no explanation why an ISP should apply better privacy protectio= ns >> to their customers DNS data compared to the customers network traffic >> because both enable a significant monitoring of the users' online >> activities. Do you have an explanation for this? > Yes. ISP/Telcos are usually big organisations. DNS mostly is seen as > a network function and thus is within some kind of engineering departme= nt. > Engineers have a different mindset on data then say people working in a= > marketing department, which usually is where these advertising programs= > originate. I appreciate your effort to explain these things to me. However, I did not understand in which department of these big organisations network traffic interception is located. Anyway, I think its time to improve the data protection of DNS before the engineering department gets involved in those advertising programs. Erik --------------ms050803060703050100030401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjExOTUzNTVaMC8GCSqGSIb3DQEJBDEiBCC7jVQpiVUC CpXCs8cyuPi+h7nc3l7Xufq9Cc5OFzRw9DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQC5gMJ2eg5HIG/GSNtyX1so9LiVp91QNRtvmufT OFp3JoLSju1JZ29u91mtCmVOxevz8iGMRaqbuhqI+ZuAB3zrOUCH2k8Rh6R54zFXPIWNnlMT eb/MiKGcRqQbcoQlAirqWkBDI3u5OeZu/pwG9+3AjEYrVZzlKTzMChpE1NA+DcwJyzbImX37 28cC+yaRsPbMItVHbiUGgO9eXqu/pro4CJL2nzBIMXd92Rb55rY44+rUIYWOpgvV2A0HUcla k6WkCHPaHSzRCgIFL7Q49VbGtSICxNsmQD4LmGDRK17XAKdxD+pS4XtAR546z9UMoY9YLzE/ cS7NQL+d2y27PckeAAAAAAAA --------------ms050803060703050100030401-- From nobody Wed Aug 21 13:03:49 2019 Return-Path: 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 B62DA120805 for ; Wed, 21 Aug 2019 13:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 BZsJQ0XSYaY6 for ; Wed, 21 Aug 2019 13:03:44 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109391209F0 for ; Wed, 21 Aug 2019 13:03:41 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C5E2A892E8; Wed, 21 Aug 2019 20:03:40 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Wed, 21 Aug 2019 20:03:21 +0000 Message-ID: <9495312.8Az2s6tnoE@linux-9daj> Organization: none In-Reply-To: <7ad31866-66c8-7f50-50b4-775993ae1267@informatik.uni-hamburg.de> References: <20190819203948.2BE688829F4@ary.qy> <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> <7ad31866-66c8-7f50-50b4-775993ae1267@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:03:48 -0000 On Wednesday, 21 August 2019 19:53:55 UTC Erik Sy wrote: > ... Anyway, I think its time to improve the > data protection of DNS before the engineering department gets involved > in those advertising programs. because we have to secure the whole internet system, and not just the subset of that system called the web, dns itself has been the subject of massive change over the last two decades to improve its data protection. the idea of having a web object tell my web browser which malware server to go to in order to download a bitcoin miner, without being subject to either control or monitoring by my private network operator (parental controls, or corporate security), should terrify pretty much everybody. we need the internet system to be secure, including its naming system, and not on an app-by-app (such as the web, which to the internet is just an app) basis. embedding dns content in web object secures against only one attack, and only within the confines of one app. the rest of the problem will remain, except, the web as an app wouldn't benefit from the rest of those solutions. -- Paul From nobody Wed Aug 21 13:09:18 2019 Return-Path: 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 C1CDB120120 for ; Wed, 21 Aug 2019 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 S9cUBsXr3q0H for ; Wed, 21 Aug 2019 13:09:14 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F2F12006A for ; Wed, 21 Aug 2019 13:09:14 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id x4so4637685qts.5 for ; Wed, 21 Aug 2019 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JU+74fGLuIV/KO3YLLy5SjxK017OCkeOZbrOT4vZi0c=; b=pNKPuazX7FEL6KMU30OO2vzp7d1EgC9JhimO3zjg2KSv6dkVvMNcTS7b7dx7a0FiKV mjAy1qxKgM68UIQzhXY8OXEZTZu2WYz3Hc2CWuafqEo/vt98OG7wvtIyZYOaxiovUnqA KAF/esKTxz08TRPthwZ4eC/7zLG7vgVNbtZIveJTEfs0pWy+4qqjGMpPPctdaH1vQrjq csqHJGwEMWlHYUf2/wZQyAzeZsKEKYAV6oyVrHTqNgIAsQuosfZGeXKfcNmNX/ZR7NVL 3ZgARGJwxJ2Q0q5GIo+0g5HGtb+owPGtU2otN/jJLEv+o3f/xJwNlrbVbd8QDEy3cKZh 1PbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JU+74fGLuIV/KO3YLLy5SjxK017OCkeOZbrOT4vZi0c=; b=tMfUxAl8xwJbyibvVqNzAHBHFkh+kg4WD7o2z/C2cB4piI7BgQ6QysFX7HTK+QK0OV DKuskpQD5N4DtSXJD1to3wSNM2nXVwEErGlOjF/gHZ0bJBG2O3L+vietUAwSSNxbF5Pp jyYjWgtAWrKvSbNhLSxuliHb8d903DJlm3gb6UqCw5iEP6s68YQfNFJ8dHBxqB9hEMbx KFzUjjzYz3jUVkf1E7SHd/BwyJJKSjNHO9S5ENUZr+EgW73bO2P77ddJ8OJGDyjSKhUY WOm+oeI6UML1B7E0cEnA9nPeR9YfjA7RpmPB8ZP2XMXHZgpq01bk4jsMO0wYlpDYxGN0 O+7Q== X-Gm-Message-State: APjAAAXLy6zwO0J6fvLD60cVn4nI7AG9AGAOIfiA9qBZtB3ls+HYA6I+ 1/PMReSAhkPTidxd7FdFOks4Vw== X-Google-Smtp-Source: APXvYqxMQCm5rR9MEI84MoaHx1DofuwSKR/YhSYfbeMilgP/cL4P4toNdAMqF0OdMAvZVRptVssq4g== X-Received: by 2002:ac8:b87:: with SMTP id h7mr17341874qti.384.1566418153655; Wed, 21 Aug 2019 13:09:13 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:dcad:b652:a407:815b? ([2001:470:c1a2:1:dcad:b652:a407:815b]) by smtp.gmail.com with ESMTPSA id b126sm10707366qkg.17.2019.08.21.13.09.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 13:09:13 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EEF771A8-DA33-4270-977B-0FBA8D1C9BA6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 21 Aug 2019 16:09:11 -0400 In-Reply-To: <9495312.8Az2s6tnoE@linux-9daj> Cc: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de To: Paul Vixie References: <20190819203948.2BE688829F4@ary.qy> <11C3BC62-667E-40E9-ADD7-D33C72DA29F2@fl1ger.de> <7ad31866-66c8-7f50-50b4-775993ae1267@informatik.uni-hamburg.de> <9495312.8Az2s6tnoE@linux-9daj> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:09:17 -0000 --Apple-Mail=_EEF771A8-DA33-4270-977B-0FBA8D1C9BA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 21, 2019, at 4:03 PM, Paul Vixie wrote: > the idea of having a web object tell my web browser which malware = server to go=20 > to in order to download a bitcoin miner, without being subject to = either=20 > control or monitoring by my private network operator (parental = controls, or=20 > corporate security), should terrify pretty much everybody. How would you prevent that? The web page can always embed an IP = address. --Apple-Mail=_EEF771A8-DA33-4270-977B-0FBA8D1C9BA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Aug 21, 2019, at 4:03 PM, Paul Vixie <paul@redbarn.org> = wrote:
the idea of = having a web object tell my web browser which malware server to go 
to in order = to download a bitcoin miner, without being subject to either 
control or = monitoring by my private network operator (parental controls, or 
corporate = security), should terrify pretty much = everybody.

How would you prevent that?  The web page can always = embed an IP address.

= --Apple-Mail=_EEF771A8-DA33-4270-977B-0FBA8D1C9BA6-- From nobody Wed Aug 21 13:26:55 2019 Return-Path: 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 9D43D120091 for ; Wed, 21 Aug 2019 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_RUURL=3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HKpa3GoC6Wci for ; Wed, 21 Aug 2019 13:26: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 C0D6312002E for ; Wed, 21 Aug 2019 13:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 55D123AE for ; Wed, 21 Aug 2019 22:26: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 SMKr2uWK4FV5 for ; Wed, 21 Aug 2019 22:26:48 +0200 (CEST) Received: from users-MBP.fritz.box (mue-88-130-89-191.dsl.tropolys.de [88.130.89.191]) (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 402703AD for ; Wed, 21 Aug 2019 22:26:47 +0200 (CEST) To: resolverless-dns@ietf.org References: <20190819170749.5AEF588004D@ary.qy> <1120786282.10734.1566296601469@appsuite-gw2.open-xchange.com> <13289521-3977-886e-ddfa-d7fc4728912e@informatik.uni-hamburg.de> <1510635197.4293.1566376955811@appsuite-gw1.open-xchange.com> From: Erik Sy 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: <36c317b7-19a1-2052-3193-5c3bd35fcfca@informatik.uni-hamburg.de> Date: Wed, 21 Aug 2019 22:26:46 +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: <1510635197.4293.1566376955811@appsuite-gw1.open-xchange.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020704010602030700020609" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:26:53 -0000 This is a cryptographically signed message in MIME format. --------------ms020704010602030700020609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/21/19 10:42, Vittorio Bertola wrote: >> Il 20 agosto 2019 21:08 Erik Sy ha scri= tto: >> =20 >> On 8/20/19 12:23, Vittorio Bertola wrote: >>> Also, when filtering is applied for human dignity reasons (e.g. to bl= ock racist content, terrorist websites, child porn etc.) you explicitly d= o not want to publish the list of blocked destinations, as it would be an= easy directory for wannabe racists/terrorists/pedophiles... >>> >> The better way to handle illegal content online is the notice and >> takedown approach > Unfortunately, the notice and takedown approach works only if the conte= nt is hosted within the country. It just takes a credit card for the crim= inal to buy hosting somewhere else on the planet, and at that point, if y= ou are lucky the international takedown process takes a long time, and if= you are unlucky the criminal will find a country which doesn't care (the= re's a big one just east of the EU) It seems that you claim that notice and takedown is not successful in Russia. However, I think that the opposite is the case. Based on [1] the organization friendlyrunet.ru managed to remove child pornography in 14754 out of 15580 cases during the reported year. Thus, notice and takedown was successful in about 95% of the cases. > or even a country in which that specific content is legal. I agree that notice and takedown requires the specific content to be illegal in the country where it is hosted. Erik 1: http://www.friendlyrunet.ru/files/43/2013-Liga-AnnualReport-ENg.pdf --------------ms020704010602030700020609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjEyMDI2NDdaMC8GCSqGSIb3DQEJBDEiBCDtx3jn3STn YlIJSGL8Sc12AcmWZB5PgfsI8Pg5zvk8EDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQA6xeHKcwmvSx/vZYO1VM/f9M4vJn1t24c1N25m yYSXJ2NDopoEtY5Tr/WS85OJaftkZVPnBJf6tChhSOtkfYVlEV+ny0cqAyuyzl8K+zZ9NGUX vn5rvlBCusjJOXgcahUU2oSjeGQO/o8NIZ/roKW/vYInNsjS1qckWT9rmun9QN9zc6jaofC0 WztQWbAoo0tGYxdQ/bFuKBY7JhSchAPKG48iaOzZwAmJPiYXFKhellALe+BBZdkbvf9uE2y4 hxC9OkQgRFvwCPwhPIWSC8CVBXxtsshIUSj9ijBWZbBAMM4xa/ayM0CPG87Zbm0Xz7NyLQLf jgU40JvaqWqCdSnQAAAAAAAA --------------ms020704010602030700020609-- From nobody Wed Aug 21 18:08:53 2019 Return-Path: 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 717BA120132 for ; Wed, 21 Aug 2019 18:08:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ve-E-br-LbAT for ; Wed, 21 Aug 2019 18:08:50 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5539C12010E for ; Wed, 21 Aug 2019 18:08:50 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 33FA2892E8; Thu, 22 Aug 2019 01:08:49 +0000 (UTC) From: Paul Vixie To: Ted Lemon Cc: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Thu, 22 Aug 2019 01:08:48 +0000 Message-ID: <1950174.j2oo942mI2@linux-9daj> Organization: none In-Reply-To: References: <20190819203948.2BE688829F4@ary.qy> <9495312.8Az2s6tnoE@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 01:08:52 -0000 On Wednesday, 21 August 2019 20:09:11 UTC Ted Lemon wrote: > On Aug 21, 2019, at 4:03 PM, Paul Vixie wrote: > > the idea of having a web object tell my web browser which malware server > > to go to in order to download a bitcoin miner, without being subject to > > either control or monitoring by my private network operator (parental > > controls, or corporate security), should terrify pretty much everybody. > > How would you prevent that? The web page can always embed an IP address. my experience with HSTS is that dotted-quad links are nearly impossible to use from an HTTPS web object, since they point either to an HTTP web object (which is a downgrade) or do an HTTPS object whose SNI is a dotted quad (which is hard to get a certificate for.) in any case it's not common and those may be the reasons. defacement attacks rely on the ability to move their ultimate payload around and they use a DNS name as an indirection layer so that they can keep it available during cat and mouse takedown games. if linking to dotted quads worked securely and robustly, i expect that we'd see more of this in the non-criminal web, and less pressure for "resolverless dns" as a way to avoid DNS lookups. -- Paul From nobody Wed Aug 21 18:21:46 2019 Return-Path: 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 0753212013F for ; Wed, 21 Aug 2019 18:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 wXp5soEosgyF for ; Wed, 21 Aug 2019 18:21:43 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD39312013D for ; Wed, 21 Aug 2019 18:21:42 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id k13so5537032qtm.12 for ; Wed, 21 Aug 2019 18:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uNWBHeeOZqGUCyFxpE7wf8hrJ+BtRg6n08YcvBh+3AI=; b=m/KWCHKC/ag520QbLxB7B23YO6eeXF7l1SZ5so3fSd5yw7LFiCi8ZG3tShPjZeddGo nRaI74+4o+25OmpVwGPKfQupvlqnyUzDOux/XDunpGEev4yZX4WtWHweVSyh+1y+RoQJ 5U9cbY0//VDj9n2DlyAvWBNW8+ewD8gMu5Edivi+HqQEfS1JQqMhbbOKi4dK5ZhReOXS keu7lMauqMyLBVAwTPVv2p4331B3rkHeD68NWkWFcbME3nsTXtm2lCusAJ/eDY2D1+o7 +HHZLItdHA+Nhhh0G2QXUmp9SLVl6KIjC+K55X7Rjm5fG8wKyFdCeWkDzjE5aI+tFU3d 3xeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uNWBHeeOZqGUCyFxpE7wf8hrJ+BtRg6n08YcvBh+3AI=; b=bD1eyaoEOG8diRq1D8tt3hGEoOpPCoUKRL9xZL7fMiVnf7SdoogZY13zXduxJbe77N liYlN8AYL4//LSKaPyoS/WcEiZC04M2ff6k5PR44/BTsyHG3tZtCGii4g9uvs/8tSMRt 75SLxtc87q17mAtnaqUF23GTh588+k59wOO14bdLuVb7TI566peS8X7AxGpXmN5y8fjY I6cc/u39XiExER9sMlnguYabuMQDmmIduKtNy5NQO8Wajo2zrakn6ZK+FYz+rWUjWuTq 3yIfnsz2hZOUJULIySa7t1dhv0DWlO5P9lzz3amhvnEIAFnPUrRJleZ2XByBZmZWIqYs fI5Q== X-Gm-Message-State: APjAAAU8zTmROavgW2CwQx22LfBTQmcIezlqNSIdv1EoiolLnz6GtVA7 THARqxRJhH4ipA4apayU/5n56w== X-Google-Smtp-Source: APXvYqwDuy48itsU1Uy/ia2a/GGB1+TPwYDck2PDNZ+595gF9MGwYwfq2g47/AbItwym7wgTzpKqNg== X-Received: by 2002:aed:3327:: with SMTP id u36mr33080281qtd.94.1566436901800; Wed, 21 Aug 2019 18:21:41 -0700 (PDT) Received: from [10.0.100.10] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b18sm10593717qkc.112.2019.08.21.18.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 18:21:41 -0700 (PDT) From: Ted Lemon Message-Id: <1CC6D47E-181D-41F8-AC7C-AB2E78E32AE0@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B35A4B7-9B3E-481E-97C5-EE7C034910C4" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) Date: Wed, 21 Aug 2019 21:21:40 -0400 In-Reply-To: <1950174.j2oo942mI2@linux-9daj> Cc: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de To: Paul Vixie References: <20190819203948.2BE688829F4@ary.qy> <9495312.8Az2s6tnoE@linux-9daj> <1950174.j2oo942mI2@linux-9daj> X-Mailer: Apple Mail (2.3578.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 01:21:45 -0000 --Apple-Mail=_2B35A4B7-9B3E-481E-97C5-EE7C034910C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 21, 2019, at 9:08 PM, Paul Vixie wrote: > my experience with HSTS is that dotted-quad links are nearly = impossible to use=20 > from an HTTPS web object, since they point either to an HTTP web = object (which=20 > is a downgrade) or do an HTTPS object whose SNI is a dotted quad = (which is=20 > hard to get a certificate for.) Thanks, that=E2=80=99s a good point. So to describe what is going on = here, what you are saying is that the browser provides no avenue of = endpoint identification and authorization other than DNS? --Apple-Mail=_2B35A4B7-9B3E-481E-97C5-EE7C034910C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 21, 2019, at 9:08 PM, Paul Vixie <paul@redbarn.org> = wrote:
my experience = with HSTS is that dotted-quad links are nearly impossible to use 
from an HTTPS = web object, since they point either to an HTTP web object (which 
is a = downgrade) or do an HTTPS object whose SNI is a dotted quad (which = is 
hard to get a = certificate for.)

Thanks, that=E2=80=99s a good point.   So to describe = what is going on here, what you are saying is that the browser provides = no avenue of endpoint identification and authorization other than = DNS?

= --Apple-Mail=_2B35A4B7-9B3E-481E-97C5-EE7C034910C4-- From nobody Wed Aug 21 18:47:52 2019 Return-Path: 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 C21C3120086 for ; Wed, 21 Aug 2019 18:47:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 l81QfMEjGfVc for ; Wed, 21 Aug 2019 18:47:49 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FF312003F for ; Wed, 21 Aug 2019 18:47:49 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 39AFA892E8; Thu, 22 Aug 2019 01:47:48 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Cc: Ted Lemon , sy@informatik.uni-hamburg.de Date: Thu, 22 Aug 2019 01:47:47 +0000 Message-ID: <1781914.51cSh5WzdD@linux-9daj> Organization: none In-Reply-To: <1CC6D47E-181D-41F8-AC7C-AB2E78E32AE0@fugue.com> References: <20190819203948.2BE688829F4@ary.qy> <1950174.j2oo942mI2@linux-9daj> <1CC6D47E-181D-41F8-AC7C-AB2E78E32AE0@fugue.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 01:47:51 -0000 On Thursday, 22 August 2019 01:21:40 UTC Ted Lemon wrote: > On Aug 21, 2019, at 9:08 PM, Paul Vixie wrote: > > my experience with HSTS is that dotted-quad links are nearly impossible= to > > use from an HTTPS web object, since they point either to an HTTP web > > object (which is a downgrade) or do an HTTPS object whose SNI is a dott= ed > > quad (which is hard to get a certificate for.) >=20 > Thanks, that=E2=80=99s a good point. So to describe what is going on he= re, what > you are saying is that the browser provides no avenue of endpoint > identification and authorization other than DNS? i don't know that part. i do know i stop a lot of crud with DNS RPZ, for=20 myself and my customers, and that if web browsers stop asking DNS questions= ,=20 the defense methods i'm using and recommending will work less often. =2D-=20 Paul From nobody Wed Aug 21 19:39:43 2019 Return-Path: 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 330E2120048 for ; Wed, 21 Aug 2019 19:39:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 ZTGhMLOIuX8o for ; Wed, 21 Aug 2019 19:39:40 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46391120019 for ; Wed, 21 Aug 2019 19:39:40 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 125so3809279qkl.6 for ; Wed, 21 Aug 2019 19:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=l16/xkLDFQHh3V+XQQCf5SKESDhznhiXa8pydiIGLsg=; b=obf7GhVXTPXphwJgxSq8DOYqMKNXB9+rFoW83R0ZjbZq1cQhct5GFPFpXoqh7gdmvi T1l7U0dLh4jloMQJn5Gep+CppCO6z9dt0Dsf919yD1SQC+aPlatb+2sMOk9KJkiU9Vnd jRjk3fawywoJegCNK9r9lMmKit8LhVO1g88hc8b4/FVx2EWLUap9atgVEBAUSQvZ6EbG I39r49JZvxOMJz6mAiCYZK6xVymw+UEmvPa145vhj8zxVQGazI0MsavC9kDAY2pwtsmd ZGOsSaulnH+ZPTxA2R7Lol9p/zHXlsPW3wumvigFFLMjCF49FPhCANFBn7ZxzWEXI6zX 3fLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=l16/xkLDFQHh3V+XQQCf5SKESDhznhiXa8pydiIGLsg=; b=hKZ9ICUCd+iDZx6XOZUjNnL5YWwrLD/SKCsCDOE2F81fgh0iVWZq7i02lGNyWVGLJP V1RI+cR122/7iIPoecRGs31CYe+7eKXnexzat4KIl91BDvPoYZNHZ2A+dusxxmtz8fNw gCcama639+KMiCDG0uGFVP/u19re1zBetWxvLSLgr//fHrrhx1IThK0Sj5HCKbq5vMmX WrQ2GWfmjf7eGrdK8Inw5rwcISdFOLrcT462n2qBRqc71d74ouDvlHXzKTvdiObNLD16 rqhdolHaF8Gei1keWXen2LrI4pW+u1zH2OBpbO3XMdI150hgAWctRzx29Ev0/5nPMp6W hUBg== X-Gm-Message-State: APjAAAVJIYs7snWc41CpnJ704sIK+45kFq1ZwIKDqSlgrmzMV0EeQ7f/ UNROfV2xtSQASvclR5bozAbtzpqyGO66mg== X-Google-Smtp-Source: APXvYqx9ZcOoS5JS+OLz6DJc9lWbDoOHUEyStCKALd/OIbjk1eLonEigovWTY0yKidR4rXzFiJt/Mg== X-Received: by 2002:ae9:edc1:: with SMTP id c184mr32961071qkg.418.1566441579024; Wed, 21 Aug 2019 19:39:39 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id h2sm10698485qto.81.2019.08.21.19.39.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Aug 2019 19:39:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 21 Aug 2019 22:39:37 -0400 Message-Id: References: <1781914.51cSh5WzdD@linux-9daj> Cc: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de In-Reply-To: <1781914.51cSh5WzdD@linux-9daj> To: Paul Vixie X-Mailer: iPhone Mail (17A573) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 02:39:42 -0000 So, for your use case it would be good if there were a way for authorized de= vices to know that they are connected to your network and use your resolvers= , and a way to quarantine devices that have not been configured that way. Or= you could just have always use your resolver if they are willing.=20 Sent from my iPhone > On Aug 21, 2019, at 21:47, Paul Vixie wrote: >=20 > =EF=BB=BFOn Thursday, 22 August 2019 01:21:40 UTC Ted Lemon wrote: >>> On Aug 21, 2019, at 9:08 PM, Paul Vixie wrote: >>> my experience with HSTS is that dotted-quad links are nearly impossible t= o >>> use from an HTTPS web object, since they point either to an HTTP web >>> object (which is a downgrade) or do an HTTPS object whose SNI is a dotte= d >>> quad (which is hard to get a certificate for.) >>=20 >> Thanks, that=E2=80=99s a good point. So to describe what is going on he= re, what >> you are saying is that the browser provides no avenue of endpoint >> identification and authorization other than DNS? >=20 > i don't know that part. i do know i stop a lot of crud with DNS RPZ, for=20= > myself and my customers, and that if web browsers stop asking DNS question= s,=20 > the defense methods i'm using and recommending will work less often. >=20 > --=20 > Paul >=20 >=20 From nobody Wed Aug 21 20:08:34 2019 Return-Path: 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 1AAFE12003F for ; Wed, 21 Aug 2019 20:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 T82EoL2Wp4kS for ; Wed, 21 Aug 2019 20:08:32 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2969E120018 for ; Wed, 21 Aug 2019 20:08:32 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 02A91892E8; Thu, 22 Aug 2019 03:08:31 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Cc: Ted Lemon , sy@informatik.uni-hamburg.de Date: Thu, 22 Aug 2019 03:08:31 +0000 Message-ID: <1827562.zAUzFULyIp@linux-9daj> Organization: none In-Reply-To: References: <1781914.51cSh5WzdD@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 03:08:33 -0000 On Thursday, 22 August 2019 02:39:37 UTC Ted Lemon wrote: > So, for your use case it would be good if there were a way for authorized > devices to know that they are connected to your network and use your > resolvers, and a way to quarantine devices that have not been configured > that way. Or you could just have always use your resolver if they are > willing. i don't love the term "use case" for this. the onus of justification is upon she who would change from the status quo. what i've asked is that this behaviour rely on a secure and reliable signal from the system's resolver that it has no objections to the use of some other data path for DNS. if the system's resolver doesn't signal either way, then don't use any other data path for DNS. its reasons may be filtering, or monitoring, or the principle of least astonishment, or moonshine. in other words its reasons don't matter. -- Paul From nobody Thu Aug 22 14:12:08 2019 Return-Path: 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 CD2521200A4 for ; Thu, 22 Aug 2019 14:12:05 -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 2andxuIvKhVB for ; Thu, 22 Aug 2019 14:12:03 -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 388E5120C8B for ; Thu, 22 Aug 2019 14:12:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 3D0096F2 for ; Thu, 22 Aug 2019 23:12:01 +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 aOlTmbPtr3EG for ; Thu, 22 Aug 2019 23:12:00 +0200 (CEST) Received: from users-MBP.fritz.box (i577AFB9D.versanet.de [87.122.251.157]) (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 528826F1 for ; Thu, 22 Aug 2019 23:11:59 +0200 (CEST) To: resolverless-dns@ietf.org References: <4912129.Q1cc77n183@linux-9daj> <4568720.uvMTqBdgP4@linux-9daj> From: Erik Sy 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: Date: Thu, 22 Aug 2019 23:11:58 +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: <4568720.uvMTqBdgP4@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000306030805010908000403" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 21:12:06 -0000 This is a cryptographically signed message in MIME format. --------------ms000306030805010908000403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/20/19 23:12, Paul Vixie wrote: >> I assume that by >> referring to DNSSEC and DANE, you do not want to claim that some popul= ar >> client software is strictly enforcing a validation of DNS records usin= g >> DNSSEC and DANE, right? > caching resolvers everywhere, do this. This study shows that only about 12% of the resolvers use DNSSEC to validate the records [1]. > the economy depends on them doing so. I find that only 0.9% of the .com domains are signed [2] and having a signature does not mean that they can be successfully validated. > if RDNS isn't client software from your point of view, you'll dismiss t= hese=20 > assertions. RDNS requires the client to trust the used recursive resolver. In my view, the client should be able to validate the DNS records independently of the recursive resolver. I think there is a security benefit for clients in using TLS server authentication to validate DNS records at least in the context of web browsing. Erik 1: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-chu= ng.pdf 2: https://www.statdns.com/ --------------ms000306030805010908000403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjIyMTExNThaMC8GCSqGSIb3DQEJBDEiBCBOZalKkaAe dKQC6d7QAsyAwf7aiEkjfR1lXBfXNRMtdDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAuRE72JZZTbIdUSfEYIJhrZ8N0MkYeZhRV4HMF GPWNOD07q4UzluvGt/LLLUGM0Ggjubw2oQOLHGgRhSMQKcOAY5XjAwApU6pr0NrBQWpotRHC afHHfx15qc4t98BZwb0yU3BJEPh0EoKJlja7cYQOs6plXTIFDqlvBQdzF5NCohI0cuMwdzsE 2yoJyeiqIp66NWO4Mt/yfdEw8aeB5pD1aYTYw4ICCyEqKSRMqzL2lpilvm+SpPO5L19XMLct NqBXfz5hNraEqjklZAB2xdvWG9YgZ7UP3o12v+KJ0mjTjqerpJ8SIqqvKx2GT6DMbLEZWREn wDYG4ygfsIoca7LGAAAAAAAA --------------ms000306030805010908000403-- From nobody Thu Aug 22 14:51:04 2019 Return-Path: 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 BD31C120C2F for ; Thu, 22 Aug 2019 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZxDbbqO7V09k for ; Thu, 22 Aug 2019 14:51:01 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A6C12012E for ; Thu, 22 Aug 2019 14:51:01 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C2597892E8; Thu, 22 Aug 2019 21:50:59 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de Date: Thu, 22 Aug 2019 21:50:58 +0000 Message-ID: <34813218.VKkrhzyXsx@linux-9daj> Organization: none In-Reply-To: References: <4568720.uvMTqBdgP4@linux-9daj> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1763975.AAR2ODdUOy" Content-Transfer-Encoding: 7Bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 21:51:03 -0000 This is a multi-part message in MIME format. --nextPart1763975.AAR2ODdUOy Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, 22 August 2019 21:11:58 UTC Erik Sy wrote: > On 8/20/19 23:12, Paul Vixie wrote: > >> I assume that by > >> referring to DNSSEC and DANE, you do not want to claim that some popular > >> client software is strictly enforcing a validation of DNS records using > >> DNSSEC and DANE, right? > > > > caching resolvers everywhere, do this. > > This study shows that only about 12% of the resolvers use DNSSEC to > validate the records [1]. i think that in 2017 when that report was published, their 12% was very well distributed, geographically and topologically, and that it represents a disproportionate share of lookup transactions. > > the economy depends on them doing so. > > I find that only 0.9% of the .com domains are signed [2] and having a > signature does not mean that they can be successfully validated. i suggest you broaden your search for knowledge. for example, this web site may be of interest, along with the monthly reports posted to dns-operations@ by the same authors. https://stats.dnssec-tools.org/[1] > > if RDNS isn't client software from your point of view, you'll dismiss > > these assertions. > > RDNS requires the client to trust the used recursive resolver. not for DANE work flows. stub validation is not widely implemented or well supported by DNSSEC, but it works, and existing DANE TLSA clients do this. > In my view, the client should be able to validate the DNS records > independently of the recursive resolver. we agree. > I think there is a security > benefit for clients in using TLS server authentication to validate DNS > records at least in the context of web browsing. we disagree, for reasons i won't repeat here a second time. -- Paul -------- [1] https://stats.dnssec-tools.org/ --nextPart1763975.AAR2ODdUOy Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, 22 August 2019 21:11:58 UTC Erik Sy wrote:

> On 8/20/19 23:12, Paul Vixie wrote:

> >> I assume that by

> >> referring to DNSSEC and DANE, you do not want to claim that some popular

> >> client software is strictly enforcing a validation of DNS records using

> >> DNSSEC and DANE, right?

> >

> > caching resolvers everywhere, do this.

>

> This study shows that only about 12% of the resolvers use DNSSEC to

> validate the records [1].

 

i think that in 2017 when that report was published, their 12% was very well distributed, geographically and topologically, and that it represents a disproportionate share of lookup transactions.

 

> > the economy depends on them doing so.

>

> I find that only 0.9% of the .com domains are signed [2] and having a

> signature does not mean that they can be successfully validated.

 

i suggest you broaden your search for knowledge. for example, this web site may be of interest, along with the monthly reports posted to dns-operations@ by the same authors.

 

https://stats.dnssec-tools.org/

 

> > if RDNS isn't client software from your point of view, you'll dismiss

> > these assertions.

>

> RDNS requires the client to trust the used recursive resolver.

 

not for DANE work flows. stub validation is not widely implemented or well supported by DNSSEC, but it works, and existing DANE TLSA clients do this.

 

> In my view, the client should be able to validate the DNS records

> independently of the recursive resolver.

 

we agree.

 

> I think there is a security

> benefit for clients in using TLS server authentication to validate DNS

> records at least in the context of web browsing.

 

we disagree, for reasons i won't repeat here a second time.

 

--

Paul

--nextPart1763975.AAR2ODdUOy-- From nobody Fri Aug 23 02:37:12 2019 Return-Path: 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 46ABA1207FC for ; Fri, 23 Aug 2019 02:37:10 -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 KKUDS0n-NCDZ for ; Fri, 23 Aug 2019 02:37:08 -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 E8F81120125 for ; Fri, 23 Aug 2019 02:37:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 292EDC07 for ; Fri, 23 Aug 2019 11:37:06 +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 1dcdeYShLBse for ; Fri, 23 Aug 2019 11:37:05 +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 DB754C06 for ; Fri, 23 Aug 2019 11:37:04 +0200 (CEST) To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> From: Erik Sy 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: Date: Fri, 23 Aug 2019 11:37:03 +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: <34813218.VKkrhzyXsx@linux-9daj> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060101020909070102080808" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 09:37:10 -0000 This is a cryptographically signed message in MIME format. --------------ms060101020909070102080808 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/22/19 23:50, Paul Vixie wrote: > > On Thursday, 22 August 2019 21:11:58 UTC Erik Sy wrote: > > > On 8/20/19 23:12, Paul Vixie wrote: > > > >> I assume that by > > > >> referring to DNSSEC and DANE, you do not want to claim that some > popular > > > >> client software is strictly enforcing a validation of DNS records > using > > > >> DNSSEC and DANE, right? > > > > > > > > caching resolvers everywhere, do this. > > > > > > This study shows that only about 12% of the resolvers use DNSSEC to > > > validate the records [1]. > > =A0 > > i think that in 2017 when that report was published, their 12% was > very well distributed, geographically and topologically, and that it > represents a disproportionate share of lookup transactions. > I read this as an argument to use one of the more popular resolvers. > =A0 > > > > the economy depends on them doing so. > > > > > > I find that only 0.9% of the .com domains are signed [2] and having a= > > > signature does not mean that they can be successfully validated. > > =A0 > > i suggest you broaden your search for knowledge. for example, this web > site may be of interest, along with the monthly reports posted to > dns-operations@ by the same authors. > > =A0 > > https://stats.dnssec-tools.org/ > > =A0 > Anyway, lets assume that all domains and resolvers perfectly support DNSSEC and that we have transport encryption between the client and the resolver. In this scenario, the client still needs to trust the resolver to provide the correct address. Furthermore, having a correctly resolved IP address does not solve the problem of communicating to the correct server, which is usually the intention of the client. > > > > if RDNS isn't client software from your point of view, you'll dismi= ss > > > > these assertions. > > > > > > RDNS requires the client to trust the used recursive resolver. > > =A0 > > not for DANE work flows. stub validation is not widely implemented or > well supported by DNSSEC, but it works, and existing DANE TLSA clients > do this. > 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/he9tr7p3rZ= 8/eNMwKPmUBAAJ > =A0 > > > In my view, the client should be able to validate the DNS records > > > independently of the recursive resolver. > > =A0 > > we agree. > Great! Any plans except for resolver-less DNS how we can do that which has a chance of being accepted by the browser vendors? Erik > =A0 > > > I think there is a security > > > benefit for clients in using TLS server authentication to validate DN= S > > > records at least in the context of web browsing. > > =A0 > > we disagree, for reasons i won't repeat here a second time. > > =A0 > > --=20 > > Paul > > --------------ms060101020909070102080808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjMwOTM3MDNaMC8GCSqGSIb3DQEJBDEiBCBPzAqW1M+e 6Ua2vGRXN1l5XkzYp8UcuQVw7myJWLbtUzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAyjlvKa/bjr2ttow7SFDVOcTozxdb/Hi39Ml4n RQp8IUHUb3zpA1eOp0gPmJ44jaS6bEK7L3Urh36lvuXxK2N+slbmvpDzVfjN4Bm0cV/pJOwf EbUkEADzDOIgbPLoggzVqaKHizv2H9LSUYuFd6SuvOQCo8rXzk08wfBkTBTE381+gF59PhVV ocAIbmbHTzWU1aMuyV0BvXsaL8gOe0N1kRasCJ21WetE3cT+7iRr3Sj38DOsblgEC8D+cDF2 lgs3nTQrntr5jjsYb5n+cCMi5tCZ4jr+LA/VsATRS6V9RqiOPeDNcb9LB/ek8o8nFupwwOBW 7b5fl1GDtgH2GQIEAAAAAAAA --------------ms060101020909070102080808-- From nobody Fri Aug 23 04:11:46 2019 Return-Path: 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 12267120810 for ; Fri, 23 Aug 2019 04:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 (2048-bit key) header.d=open-xchange.com 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 VsdIVy7H1ujx for ; Fri, 23 Aug 2019 04:11:43 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 090B51200B2 for ; Fri, 23 Aug 2019 04:11:42 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 15DC56A263; Fri, 23 Aug 2019 13:11:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566558700; bh=s+ter7bD6E9JFo1rD94yF89WtvpldmTPqQFuIuGFdE8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=vHBBFsdNZA2xnDv8ENqu0DPQq92DltFon63gRlq2/2I7ISjCA8lYRROCt7leBjsh5 PJV1vb2sT/AsNO6L8qfPyMkoiwEdPILVYWmgETT/+qphd/lB1t6T9PFZpg+ZPBGjSl dYpdLGMuEDL2Nmi31h63xVr5StI0gRR8hek3tnTGhrHP+/iSGeltIR5lrxaHRe1PVi eNPg+laoDe2NSb9JfTw8PKCebhPtWFWkSYAm0vmZb/tDtyb0W2SaYd0H8fHZXrLvg6 eWb1Hd4Xv0/HrQ/KSgadfCBPAEDfZz1bXja9Va8vOjjetRQzmUOI0nJLRqBQIR+0e6 JNuaE8dPmjbTw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 09A663C056C; Fri, 23 Aug 2019 13:11:40 +0200 (CEST) Date: Fri, 23 Aug 2019 13:11:39 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org Message-ID: <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> In-Reply-To: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev11 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 11:11:45 -0000 > Il 23 agosto 2019 11:37 Erik Sy 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. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Aug 23 04:50:56 2019 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 23 Aug 2019 13:50:48 +0200 (CEST) To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> Reply-To: sy@informatik.uni-hamburg.de From: Erik Sy 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 11:50:54 -0000 This is a cryptographically signed message in MIME format. --------------ms050307060103040409070807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/23/19 13:11, Vittorio Bertola wrote: >> Il 23 agosto 2019 11:37 Erik Sy ha scri= tto: >> >> 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 Chrom= e >> browser deprecated this mechanism last year [1]. Assuming that DANE TL= SA >> 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/he9tr7p= 3rZ8/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 pinne= d certificate matched the set of CAs that would be available in browsers = at any time in the future, and the chain of intermediate certificates tha= t each CA could use. This is not a problem with DANE, since DANE validate= s the certificate for the current connection and not for the future (so i= t's not really pinning it, just validating it every time), and does not d= epend on CAs and on the browser's acceptance of them. Even "hostile pinni= ng" 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 quit= e 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? --------------ms050307060103040409070807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjMxMTUwNDdaMC8GCSqGSIb3DQEJBDEiBCDDyaN1klIu 1MyoJh/8NPApwBEMC4SteZ1E/Z/U9n2GXjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCOTgbWW/LAUbtcEofXZr+UncaGnihs2CcGE2++ q07734k4mrqc5f6mKdh6itx6P2L+NmVib/ldU4zdQ6h+P0Dc1G52X7S35XACdWSy4cBJQaRo O9U6iFPBQT84Hw5A9jDaQH6hgQilvJlv5HJJugORFOOGab2xaROA0oNqb11BGoJfEORi0E5U HE1ZLVWylkrwa29NG9rtbcctyDKz9eDybW1YsAubQg/5cHGtMs1ybs3bbn/0Y86JtYLLx65K jTwhsJ9j0gK4lEHdRJuSqwppABPSO211MNwiRfJL/CpqfvvbJ2CiGmGdZPmQ4phJhsgnhmgR YK5/pjbv3L9Ko6s5AAAAAAAA --------------ms050307060103040409070807-- From nobody Fri Aug 23 05:05:48 2019 Return-Path: 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 50EFA12004F for ; Fri, 23 Aug 2019 05:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 (2048-bit key) header.d=open-xchange.com 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 JmvLUEWbYZDk for ; Fri, 23 Aug 2019 05:05:43 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 9876C12004E for ; Fri, 23 Aug 2019 05:05:43 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id AE1FA6A364; Fri, 23 Aug 2019 14:05:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566561941; bh=HRALkzCI2+UuI66ATyyp/FOX5TeAA/ypge8KmLKbfT4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=XHhShuFzueMIVGlQ0gWz3/qJfgcpks6OpEA/XwYV4hb1IDiq6hKuDG4FZ0rXsnY8x An6j8PLOdz2NYEF6DYdxZctoPLa2WhPJYxNtUjrrCkyGLIZ25Y4h4CY0c+a9pchMab rrCIftLShgsxsb5AYprpzfhhnYeYd+Byh4vZa1zXpAOsRR00vBwMDdvLHM30Pcg69y WiYxV0cnwKJJd5BpR0MlUfSgLWcBeHhWlxUrQP2Jt5/H62beo6fIgK7CLTatEtKCY4 tM7UjlYpl3mE/FZKqu7AjzJ1u7o87oWfKr56dmQeilk37soTZ60apSugEJ9LLWeI07 1W+5/P2wrzp5Q== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A203B3C028F; Fri, 23 Aug 2019 14:05:41 +0200 (CEST) Date: Fri, 23 Aug 2019 14:05:41 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org Message-ID: <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> In-Reply-To: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev11 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 12:05:45 -0000 > Il 23 agosto 2019 13:50 Erik Sy 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. Actually, DANE even solves some of these outages, since it will make the certificate valid even if it is not signed by a valid CA, as long as the TLSA record proves that it really comes from the entity controlling the hostname in the DNS. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Aug 23 07:27:27 2019 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 23 Aug 2019 16:27:17 +0200 (CEST) To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> From: Erik Sy 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 14:27:26 -0000 This is a cryptographically signed message in MIME format. --------------ms000405060904040606080507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/23/19 14:05, Vittorio Bertola wrote: >> Il 23 agosto 2019 13:50 Erik Sy ha scri= tto: >> >> 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 b= y the browser, because the certificate was expired and the owner forgot t= o 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 t= o stop using certificates and validating them properly - it's rather a go= od reason for the site owner to get a better webmaster.=20 > 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 --------------ms000405060904040606080507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjMxNDI3MTZaMC8GCSqGSIb3DQEJBDEiBCBOgnmrn9Ti 5pooEzDShsyKyNo+dviv+RCDu68gBXowZTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAV1PjaGDaU/fvhKMqAzmhP2vQO25Wdd3OwCCUS mg8+/oF07bb1WXrzfBMzxqwbTS8FLO0wS2Ah6xyVMObK3xgec2TC+EA7wmTenBViVoE4MbiG Yd2OL3VyKUtFtoOMqJoKX+0e1nONV9z4Xs3eJzyy30vGu6XYmNTjOU9+eKlwIYpQj0LM2vhV dH8pj/Dwtq+TednLP8XkQjIm8OlNlZaFeK6o0qdJBedKnD8IseicB1Tz2lwwf2H9u24II2DL 0fpwdOlB0jJJR4rtbgk0JpcFpp0ZQt1vzSBeyCp3kC6AZ5B8mmqUXZFRESsgLdcxzmKepOun 9gh2/B949eLirJRGAAAAAAAA --------------ms000405060904040606080507-- From nobody Sun Aug 25 11:03:18 2019 Return-Path: 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 799E21200F7 for ; Sun, 25 Aug 2019 11:03:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 mkIVfu_7stoI for ; Sun, 25 Aug 2019 11:03:14 -0700 (PDT) Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E37E12006B for ; Sun, 25 Aug 2019 11:03:13 -0700 (PDT) Received: by mail-qk1-f193.google.com with SMTP id m10so12406957qkk.1 for ; Sun, 25 Aug 2019 11:03:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fzIe1IoQPPB3ll8ue2o2fUNnTuWXKMfOTK75yF86c24=; b=PKWdEY8BaXLfYXMIYeJzmj1dXGMZQ9lJ/JgAfMJ2Qa6g48PpC81hkStkEHSlQIprze rCJjOel/RI/9RS0AsMG0j2Sx4RaQQlzBaF7cgeVULf7SA1s3A44bTs3gboIm8IBg6qRW QJUNZYgl4usx3uZYGxbcL0dElLlhO1Rb2us/KS0novmtLH1E30u2iiT+OgpFnKC6ivre GfNdvRn6awLX9DCXPuEeFR0R0oWvhGVDask3sAtmezyZcol320Jaqn7+QbYPNYEMU9YR 5wkKy2u0AEYenaJEwcnR2TOcfkGAydviXpJfs5v0PYnbgTizjnXVfuhE6uDIxT92fiww FDbQ== X-Gm-Message-State: APjAAAUn04CPkEOv/FkxFpYBY/RqhjisTLulIz2tnEpasbaO07o63e7t G9irXDX6FxFaQLZaCMawlu85b+Az6YE= X-Google-Smtp-Source: APXvYqzf/7XW2vJDvRdMUOmUd4afyZQ3YHoEHcsKUyZwwPUeWFC2+TZeQrSTFER0peVNL8QFeDz29A== X-Received: by 2002:a05:620a:134b:: with SMTP id c11mr13532801qkl.454.1566756192907; Sun, 25 Aug 2019 11:03:12 -0700 (PDT) Received: from empty.byod.gmu.edu ([129.174.182.99]) by smtp.gmail.com with ESMTPSA id z2sm5884787qtq.7.2019.08.25.11.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 11:03:12 -0700 (PDT) From: Eric Osterweil Message-Id: <362BF53C-8B12-4A1B-8C74-7D391C2637F7@osterweil.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE18A48C-FF9B-4357-9072-A649AFBE0F4F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 25 Aug 2019 14:03:11 -0400 In-Reply-To: Cc: resolverless-dns@ietf.org To: sy@informatik.uni-hamburg.de References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:03:16 -0000 --Apple-Mail=_CE18A48C-FF9B-4357-9072-A649AFBE0F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 23, 2019, at 5:37 AM, Erik Sy = wrote: >=20 >>>> the economy depends on them doing so. >>=20 >>>=20 >>=20 >>> I find that only 0.9% of the .com domains are signed [2] and having = a >>=20 >>> signature does not mean that they can be successfully validated. >>=20 >> =20 >>=20 >> i suggest you broaden your search for knowledge. for example, this = web >> site may be of interest, along with the monthly reports posted to >> dns-operations@ by the same authors. >>=20 >> =20 >>=20 >> https://stats.dnssec-tools.org/ >>=20 >> =20 >>=20 > Anyway, lets assume that all domains and resolvers perfectly support > DNSSEC and that we have transport encryption between the client and = the > resolver. In this scenario, the client still needs to trust the = resolver > to provide the correct address. Furthermore, having a correctly = resolved > IP address does not solve the problem of communicating to the correct > server, which is usually the intention of the client. >>=20 I feel like this kind of misses the point of DANE. DANE specifies the = authoritative model for creating and verifying security associations. = One of DANE=E2=80=99s core observations is that if the A record is = securely resolved, then that same security substrate should be used to = resolve the binding of that name to a certificate/key. Said = differently, the binding of a TLS certificate to a domain name (via the = TLSA record) gives the client its assurance that is talking to the = correct server. >>>> if RDNS isn't client software from your point of view, you'll = dismiss >>=20 >>>> these assertions. >>=20 >>>=20 >>=20 >>> RDNS requires the client to trust the used recursive resolver. >>=20 >> =20 >>=20 >> not for DANE work flows. stub validation is not widely implemented or >> well supported by DNSSEC, but it works, and existing DANE TLSA = clients >> do this. >>=20 > 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. >=20 > 1: > = https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8= /eNMwKPmUBAAJ = I would say this argument also misses a fundamental point. = Architecturally, DNSSEC uses a single root TA to make domain names = unambiguous (i.e. collision-free) and verifiable, and DANE adds security = associations to certificates by the same infrastructure. It=E2=80=99s = the single-rooted verification hierarchy that makes name-to-object = verification collision-free and unambiguous, as opposed to solely = leaving it the hands of the multi-rooted Web PKI (though DANE's selector = field allows synergy w/ that model). These assurances are not (afaict) = provided by key pinning alone. =20 There is a fair amount of writing that discusses this, and numerous = presentations. I=E2=80=99m happy to provide pointers if anyone would = like. Eric --Apple-Mail=_CE18A48C-FF9B-4357-9072-A649AFBE0F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 23, 2019, at 5:37 AM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:


<snip>

the economy depends on them doing so.



I find that only 0.9% of = the .com domains are signed [2] and having a

signature does not mean that they can be successfully = validated.

 

i suggest you broaden your search for = knowledge. for example, this web
site may be of interest, = along with the monthly reports posted to
dns-operations@ = by the same authors.

 
https://stats.dnssec-tools.org/

 

Anyway, lets = assume that all domains and resolvers perfectly support
DNSSEC and that we have transport encryption between the = client and the
resolver. In this scenario, the client = still needs to trust the resolver
to provide the correct = address. Furthermore, having a correctly resolved
IP = address does not solve the problem of communicating to the correct
server, which is usually the intention of the client.


I feel like this kind of misses the point of DANE. =  DANE specifies the authoritative model for creating and verifying = security associations.  One of DANE=E2=80=99s core observations is = that if the A record is securely resolved, then that same security = substrate should be used to resolve the binding of that name to a = certificate/key.  Said differently, the binding of a TLS = certificate to a domain name (via the TLSA record) gives the client its = assurance that is talking to the correct server.

if RDNS isn't client = software from your point of view, you'll dismiss

these = assertions.



RDNS requires the client to trust the used recursive = resolver.

 

not for DANE work flows. stub validation is = not widely implemented or
well supported by DNSSEC, but it = works, and existing DANE TLSA clients
do this.

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

I = would say this argument also misses a fundamental point. =  Architecturally, DNSSEC uses a single root TA to make domain names = unambiguous (i.e. collision-free) and verifiable, and DANE adds security = associations to certificates by the same infrastructure.  It=E2=80=99= s the single-rooted verification hierarchy that makes name-to-object = verification collision-free and unambiguous, as opposed to solely = leaving it the hands of the multi-rooted Web PKI (though DANE's selector = field allows synergy w/ that model).  These assurances are not = (afaict) provided by key pinning alone.  

There is a fair amount of writing that discusses = this, and numerous presentations.  I=E2=80=99m happy to provide = pointers if anyone would like.

Eric

= --Apple-Mail=_CE18A48C-FF9B-4357-9072-A649AFBE0F4F-- From nobody Sun Aug 25 11:03:42 2019 Return-Path: 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 AFF001200B4 for ; Sun, 25 Aug 2019 11:03:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 oTQThS_qttlx for ; Sun, 25 Aug 2019 11:03:33 -0700 (PDT) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4558212006B for ; Sun, 25 Aug 2019 11:03:33 -0700 (PDT) Received: by mail-qk1-f177.google.com with SMTP id m2so12366893qkd.10 for ; Sun, 25 Aug 2019 11:03:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HkTg4kcDXPPHF/g2FKeexa/Rs/9XRKB32phD5XhZlzQ=; b=WhW93XBLGd32uK/Ou8/0dnpJhKEVkUC2pA6qrRW71x55j8H+VHCcKOJkmujAy30Nqi yTskO9U4TtkKlE5LrczahF0XxMVz4f2Fd7VV5LG7FKdtQEVE4AWQULKBqVH6Usp7H8IG ZnwveZgDGSKU02yvwujQUh/P9WgAdIZnDwTCwmtn0iRGjBDqmp+utIfAfm2VZJdwIPjy caN7WD34nP4d+0/5yh2muNLp6/RVirODQ/fWhWXsYE4lDl/YCf0yFcC7QbiasUFwQoJ7 QF/sEq9ptKisIiiosaHjY3hY0A7o1M63FXeB36ZNOnkey79YEdz4XdVMWmcuACp9cLLW xvLw== X-Gm-Message-State: APjAAAXNUJzh8FwJcOKTCrE3if/rpOqfHQy9Z/mYAgC1+803r3lS95by fNeEX+qsf4E0+FGpOqPACV2sOgUmX9Q= X-Google-Smtp-Source: APXvYqwLCRAereeKk+L2l+LVycjrgF3schBz5vGWikkfiTtFPhXNStKkF/+1SjltZXor0bcgTnb6sw== X-Received: by 2002:ae9:e313:: with SMTP id v19mr13153189qkf.22.1566756212371; Sun, 25 Aug 2019 11:03:32 -0700 (PDT) Received: from empty.byod.gmu.edu ([129.174.182.99]) by smtp.gmail.com with ESMTPSA id z2sm5884787qtq.7.2019.08.25.11.03.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 11:03:31 -0700 (PDT) From: Eric Osterweil Message-Id: <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_770C1BC4-6879-4955-AE9F-69178F2187F8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 25 Aug 2019 14:03:30 -0400 In-Reply-To: <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> Cc: resolverless-dns@ietf.org To: sy@informatik.uni-hamburg.de References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:03:36 -0000 --Apple-Mail=_770C1BC4-6879-4955-AE9F-69178F2187F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 23, 2019, at 10:27 AM, Erik Sy = wrote: >=20 >=20 > On 8/23/19 14:05, Vittorio Bertola wrote: >>> Il 23 agosto 2019 13:50 Erik Sy ha = scritto: >>>=20 >>> 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.=20 >>=20 > 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. The past is prolog: = https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-= ca-servers-103112/77170/ = DANE keeps the control of associating TLS certificates with a domain in = the hands of the domain holder/operator. CT is not a panacea, and concerns about it are still evolving. For = example, it exposes all certs from all participating CAs, and this has = been shown to have negative consequences when people do not want all of = their domain names (such as internal names) necessarily exposed for = discovery: https://dl.acm.org/citation.cfm?id=3D3278562 = >=20 > 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. If I follow your logic here, then I think this is a statement that is at = least break-even for (but likely actually in favor of) DANE. If a = certificate that is proffered over a TCP connection does not match the = TLSA record, it is proactively detected and the session initiation = fails, yes? Eric= --Apple-Mail=_770C1BC4-6879-4955-AE9F-69178F2187F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 23, 2019, at 10:27 AM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:


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.

The = past is prolog:
DANE keeps the control = of associating TLS certificates with a domain in the hands of the domain = holder/operator.

CT is not a panacea, and = concerns about it are still evolving.  For example, it exposes all = certs from all participating CAs, and this has been shown to have = negative consequences when people do not want all of their domain names = (such as internal names) necessarily exposed for discovery:


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.

If I follow your logic here, then I think this is a statement = that is at least break-even for (but likely actually in favor of) DANE. =  If a certificate that is proffered over a TCP connection does not = match the TLSA record, it is proactively detected and the session = initiation fails, yes?

Eric
= --Apple-Mail=_770C1BC4-6879-4955-AE9F-69178F2187F8-- From nobody Sun Aug 25 13:41:00 2019 Return-Path: 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 5ECFD12010C for ; Sun, 25 Aug 2019 13:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 M7B4kpoN4aJ0 for ; Sun, 25 Aug 2019 13:40:56 -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 CBAA01200B7 for ; Sun, 25 Aug 2019 13:40:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id B14D5530; Sun, 25 Aug 2019 22:40:53 +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 Fv97cW9HYSPd; Sun, 25 Aug 2019 22:40:53 +0200 (CEST) Received: from users-MBP.fritz.box (mue-88-130-91-248.dsl.tropolys.de [88.130.91.248]) (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 2FC1752F; Sun, 25 Aug 2019 22:40:51 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Eric Osterweil Cc: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> From: Erik Sy 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: Date: Sun, 25 Aug 2019 22:40:50 +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: <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040600090806000000050705" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 20:40:58 -0000 This is a cryptographically signed message in MIME format. --------------ms040600090806000000050705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/25/19 20:03, Eric Osterweil wrote: >> >> 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. A= s >> a drawback of pinning, a misconfiguration of this mechanism always lea= ds >> 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. > > If I follow your logic here, then I think this is a statement that is > at least break-even for (but likely actually in favor of) DANE. =C2=A0I= f a > certificate that is proffered over a TCP connection does not match the > TLSA record, it is proactively detected and the session initiation > fails, yes? > Here is a quote from Chris Palmer on this issue[1]: "The strength of PKP =E2=80=95 run-time enforcement with hard-fail =E2=80= =94 is also exactly its weakness. Some people are OK with the risk, but overall I think the market has spoken: HPKP has seen close to no adoption. People don't want to brick their sites. As for DANE, it would at best have the same strength/weakness of HPKP, but with the additional problems of DNSSEC." In total, it seems like Chrome does not want to deploy DANE. Erik 1: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ= 8/eNMwKPmUBAAJ --------------ms040600090806000000050705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjUyMDQwNTBaMC8GCSqGSIb3DQEJBDEiBCDPmv6R0sr/ DqeYtxo1JYJxui+I2hqb4zV0ZE16jScpMTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCSz5t8myCVJruCCpBicxYFNErB9XetMu9uS71N rud/e8e2Mie6smSuw0ju+UL8hCzYbM2p1TRaon6UyfQWZJH9444lP6qEbG4TfjfOA1PkpI06 R9i1beXnrgNzcCY+d8Bn6gYAoapQhs17gcWrKQC5GfIn8xZvXVwSdld4RVkUF4w9OXtEhtNK eCxtKTBOLjTpzyQOh3nBMdx8p7j6tEqG10QJyjganuKJCyy+5TEjOOyCupacomA5VLUq2ehQ B989UCzHiMQ2GgWatMmOexOobFysO96j7mGPGdv7TVmuJgusJ3+BYsL6E9h0TnQvZyzICMeq p1p+P0GgVFyoBBErAAAAAAAA --------------ms040600090806000000050705-- From nobody Sun Aug 25 14:29:25 2019 Return-Path: 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 6D6C9120020 for ; Sun, 25 Aug 2019 14:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 o_439EVDHzY9 for ; Sun, 25 Aug 2019 14:29:22 -0700 (PDT) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7E2120041 for ; Sun, 25 Aug 2019 14:29:22 -0700 (PDT) Received: by mail-qt1-f193.google.com with SMTP id z4so16191759qtc.3 for ; Sun, 25 Aug 2019 14:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=naQOckg18yjPSFIj+GuIx0yI++15lSFsuPlNOcgATuw=; b=b3lKey+rlLuGNzBTeEFlK2ru+iNH2TZFe5mGszrAMSskWHI/oexNbQyonAxkZ5VK9u OudQLSVKGKpCyg9Qy346ZNs7VRAXzH2r+K+aEqQAqJQw2SHn8WYI1O6U/BzLeIWK1Ewy Az0G999WWi5JXTsCM7cf4PiSUkrPXSM8kX4mKtpmUb2ILQ34rH7coxcFATyf2BmkBPTf S/KwWlLg5GENXmd82k2FD+Y4pamhH6Yn7Ww2tU6kiVAPWqAgbeYA1oD/VTvRcQ2LDBf+ mVfErvMWqWqoz7PFUmqsCoN4Vf7JS7HmofiOPlEhI10KNVdbHB7jNQ+6OBhzKFZVv8r/ B1ag== X-Gm-Message-State: APjAAAUbWF/DrzGN2sNeIdifUkCW2UVQ1+z8av0bnEyDzj3jA/45NvCW 2ctVzERuJQsgk6rZXUazH/ciQSlK55o= X-Google-Smtp-Source: APXvYqyozguckhXL3v8Ex0qctY5WW5oleBuoYpNSp6jUUHGcZMwD+UJ//jBGHfPNECa7wMkeXYSyLA== X-Received: by 2002:aed:2b01:: with SMTP id p1mr15043618qtd.33.1566768560948; Sun, 25 Aug 2019 14:29:20 -0700 (PDT) Received: from [192.168.1.219] (pool-100-15-252-74.washdc.fios.verizon.net. [100.15.252.74]) by smtp.gmail.com with ESMTPSA id i5sm7008067qti.0.2019.08.25.14.29.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 14:29:20 -0700 (PDT) From: Eric Osterweil Message-Id: <94F2A83C-F486-4EBB-B57F-FBB6AE15E978@osterweil.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_47B6671A-7B8C-4299-8555-B4581CC87188" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 25 Aug 2019 17:29:18 -0400 In-Reply-To: Cc: resolverless-dns@ietf.org To: sy@informatik.uni-hamburg.de References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 21:29:24 -0000 --Apple-Mail=_47B6671A-7B8C-4299-8555-B4581CC87188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 25, 2019, at 4:40 PM, Erik Sy = wrote: >=20 >=20 > On 8/25/19 20:03, Eric Osterweil wrote: >>>=20 >>> 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. >>=20 >> If I follow your logic here, then I think this is a statement that is >> at least break-even for (but likely actually in favor of) DANE. If a >> certificate that is proffered over a TCP connection does not match = the >> TLSA record, it is proactively detected and the session initiation >> fails, yes? >>=20 > Here is a quote from Chris Palmer on this issue[1]: > 1: > = https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8= /eNMwKPmUBAAJ = >=20 > "The strength of PKP =E2=80=95 run-time enforcement with hard-fail =E2=80= =94 is also > exactly its weakness. Some people are OK with the risk, but overall I > think the market has spoken: HPKP has seen close to no adoption. = People > don't want to brick their sites. >=20 > As for DANE, it would at best have the same strength/weakness of HPKP, > but with the additional problems of DNSSEC.=E2=80=9D I think this consideration is fundamentally too narrow. As I pointed = out (elsewhere in the previous message), DANE is part of an = architectural solution ( = https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf = ). While = browser security is a very important space, it is just one potential = application. While DANE does offer an elegant security solution for = HTTPS connections, that does not mean its benefits are limited to that = venue. To reiterate earlier points: DANE securely binds associations to names = in a generalized architecture. The architecture is composed of a = non-stationary suite of solutions. In regards to TLS, its protections = go beyond just for the browser. For instance, consider opportunistic = transport layer cert/key learning for SMTP (RFC-7672: = https://tools.ietf.org/html/rfc7672 = ). The deployment numbers for = this use are up-and-to-the-right ( = http://secspider.net/pix/tlsa-growth.png = ). However, what I think = really illustrate's DANE=E2=80=99s true potential (my own 0.02 here) is = the fact that it also enables certificate/key learning for object = security suites like S/MIME and PGP ( = https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf = ). > In total, it seems like Chrome does not want to deploy DANE. It continues to be a shame, but there=E2=80=99s always time for people = to see look at growing evidence and reconsider previous decisions. ;) Eric --Apple-Mail=_47B6671A-7B8C-4299-8555-B4581CC87188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 25, 2019, at 4:40 PM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:


On 8/25/19 20:03, Eric Osterweil wrote:

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.

If I follow your logic here, then I think this is a statement = that is
at least break-even for (but likely actually in = favor of) DANE.  If a
certificate that is proffered = over a TCP connection does not match the
TLSA record, it = is proactively detected and the session initiation
fails, = yes?

Here is a quote from = Chris Palmer on this issue[1]:
1:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/= he9tr7p3rZ8/eNMwKPmUBAAJ

"The strength = of PKP =E2=80=95 run-time enforcement with hard-fail =E2=80=94 is = also
exactly its weakness. Some people are OK with the = risk, but overall I
think the market has spoken: HPKP has = seen close to no adoption. People
don't want to brick = their sites.

As for DANE, it would at best = have the same strength/weakness of HPKP,
but with the = additional problems of DNSSEC.=E2=80=9D

I think this consideration is fundamentally too = narrow.  As I pointed out (elsewhere in the previous message), DANE = is part of an architectural solution ( https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf&= nbsp;).  While browser security is a very important space, it is = just one potential application.  While DANE does offer an elegant = security solution for HTTPS connections, that does not mean its benefits = are limited to that venue.

To = reiterate earlier points: DANE securely binds associations to names in a = generalized architecture.  The architecture is composed of a = non-stationary suite of solutions.  In regards to TLS, its = protections go beyond just for the browser.  For instance, consider = opportunistic transport layer cert/key learning for SMTP (RFC-7672: https://tools.ietf.org/html/rfc7672 ).  The = deployment numbers for this use are up-and-to-the-right ( http://secspider.net/pix/tlsa-growth.png ). =  However, what I think really illustrate's DANE=E2=80=99s true = potential (my own 0.02 here) is the fact that it also enables = certificate/key learning for object security suites like S/MIME and PGP = ( https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf ).

In total, it seems like Chrome does not want = to deploy DANE.

It = continues to be a shame, but there=E2=80=99s always time for people to = see look at growing evidence and reconsider previous decisions. = ;)

Eric


= --Apple-Mail=_47B6671A-7B8C-4299-8555-B4581CC87188-- From nobody Tue Aug 27 11:29:47 2019 Return-Path: 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 D54F712083E for ; Tue, 27 Aug 2019 11:29:45 -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 TpxWGsCNwXdA for ; Tue, 27 Aug 2019 11:29:38 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D0D12084D for ; Tue, 27 Aug 2019 11:29:34 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B8EEF3F540 for ; Tue, 27 Aug 2019 14:29:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 27 Aug 2019 14:29:33 -0400 Content-Transfer-Encoding: 7bit Reply-To: resolverless-dns@ietf.org Message-Id: <9CB98019-37C7-41A6-87B1-ACF4A7B337ED@dukhovni.org> References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:29:46 -0000 > On Aug 23, 2019, at 5:37 AM, Erik Sy wrote: > > In my view, DANE TLSA is an approach to do public key pinning. The analogy is deeply flawed. HPKP has keys pinned by *clients* that may contact the server sufficiently infrequently to make stale keys an intractable problem. HPKP is also provides no protection on first contact. With DANE, on the other hand, the keys are published in the server's DNS zone, and refreshed by the server operator's DNS administrator independently of any client activity. TLSA record TTLs are typically an hour or less, and otherwise rarely more than a day. A client that implements DANE is protected on first contact. > The web > already collected a lot of experience with public key pinning as this > can be also done using other protocols than DNS. The inevitable failure of HPKP was obvious (to me and doubtless not me alone) from the outset. Stateful client-side key pinning does not scale. DANE does not share the problems of HPKP. Yes some server operators may be negligent and publish stale TLSA RRs, but *they* can fix this promptly, just as they would with expired certificates (a TLSA record is essentially a trust-anchor, it may directly designate a trusted leaf key or in many cases a trusted issuer). Any perceived similarity between DANE and HPKP is largely the result of lack of familiarity with DANE. DANE is currently employed on 6000 SMTP MX hosts serving 1.22 million email domains. Only ~500 domains have stale TLSA records, and the number should go down as more senders enable DANE, making broken deployments more visible to negligent operators. -- Viktor. From nobody Tue Aug 27 11:45:40 2019 Return-Path: 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 12EE0120861 for ; Tue, 27 Aug 2019 11:45:32 -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 FUrFVQZ09O9G for ; Tue, 27 Aug 2019 11:45:30 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FB2120133 for ; Tue, 27 Aug 2019 11:45:29 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 488BA3F625 for ; Tue, 27 Aug 2019 14:45:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 27 Aug 2019 14:45:28 -0400 Content-Transfer-Encoding: 7bit Reply-To: resolverless-dns@ietf.org Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:45:32 -0000 > On Aug 25, 2019, at 4:40 PM, Erik Sy wrote: > > As for DANE, it would at best have the same strength/weakness of HPKP, > but with the additional problems of DNSSEC." False analogies tend to lead to irrelevant conclusions. > In total, it seems like Chrome does not want to deploy DANE. Yes, the browser vendors are presently not looking to implement DANE. The initial deployment of DANE is instead happening in SMTP. DNSSEC adoption is held back by process barriers at the registrant to registrar interface. We need a widely deployed less burdensome way to initially publish and subsequently update zone KSKs. I'd also like to see better automation of ZSK rollover. More work remains to be done to lower the barriers and increase the incentives. Ideally, more of the critiques of DNSSEC would be in the form of positive contributions to improve the tools and promote interoperable KSK management. -- Viktor. From nobody Tue Aug 27 12:23:33 2019 Return-Path: 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 624F9120827 for ; Tue, 27 Aug 2019 12:23:31 -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 F5yZTgRRUgf9 for ; Tue, 27 Aug 2019 12:23:28 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB663120236 for ; Tue, 27 Aug 2019 12:23:28 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 2EF823F83C for ; Tue, 27 Aug 2019 15:23:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: <34813218.VKkrhzyXsx@linux-9daj> Date: Tue, 27 Aug 2019 15:23:27 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: resolverless-dns@ietf.org Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:23:32 -0000 > On Aug 22, 2019, at 5:50 PM, Paul Vixie wrote: >=20 > > > the economy depends on them doing so. > >=20 > > I find that only 0.9% of the .com domains are signed [2] and having = a > > signature does not mean that they can be successfully validated. > =20 > I suggest you broaden your search for knowledge. for example, this web = site may be of interest, along with the monthly reports posted to = dns-operations@ by the same authors. > =20 > https://stats.dnssec-tools.org/=20 While the .COM zone has 0.95% DNSSEC adoption (1,349,030 domains out of 141,522,129 in yesterday's zone file), other TLDs, especially in Europe, have a much higher adoption rate. For example, the .CZ, .NL, .NO and .SE TLDs have >50% DNSSEC adoption. Below is a recent (end of May) snapshot of the top 10 TLDs by signed domain count: TLD #Domains #signed #Source ---- -------- ------- ------- .NL 5864458 3184849 = https://stats.nic.cz/stats/domains_by_dnssec/ .COM 140169031 1273294 .COM zone file .BR 4056813 1079522 = https://registro.br/estatisticas.html .SE 1453459 769879 .SE zone file .CZ 1328201 746689 = https://stats.nic.cz/stats/domains_by_dnssec/ .EU 3661899 513324 Eurid reports .PL 2615437 499529 dns.pl website .NO 772052 448640 norid.no website .FR 3388943 402472 afnic.fr website .BE 1287130 288876 DANE survey Overall, in the DNSSEC survey, there are ~10 million signed domains (delegated from "public-suffix" parent domains) out of ~260 million sampled, so the "adoption bump" in Europe brings the overall rate closer to 4%. [ FWIW, with the website updated daily, I've stopped sending monthly summaries to the dns-operations list, but could do it again if there's popular demand. ] > > > if RDNS isn't client software from your point of view, you'll = dismiss > > > these assertions. > >=20 > > RDNS requires the client to trust the used recursive resolver. > =20 > not for DANE work flows. stub validation is not widely implemented or = well supported by DNSSEC, but it works, and existing DANE TLSA clients = do this. The DANE implementation in Postfix and Exim leaves DNSSEC validation to the loopback (local) resolver, rather than duplicate (poorly) the code already present in BIND, unbound, etc. A local resolver is also useful for caching MX RRsets, RBL results, ... so is already best- practice on an MTA. While applications might use libunbound or similar to directly validate DNSSEC records, there still needs to some sort of OS service for keeping the root (and any other) trust-anchors fresh. This could of course be much more light-weight than a local caching resolver... --=20 Viktor. From nobody Tue Aug 27 12:29:28 2019 Return-Path: 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 370FC120236 for ; Tue, 27 Aug 2019 12:29:27 -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 3fnETJCTsmdv for ; Tue, 27 Aug 2019 12:29:25 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0979120089 for ; Tue, 27 Aug 2019 12:29:25 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 3C8DA3F88D for ; Tue, 27 Aug 2019 15:29:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 27 Aug 2019 15:29:24 -0400 Content-Transfer-Encoding: 7bit Reply-To: resolverless-dns@ietf.org Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:29:27 -0000 > On Aug 23, 2019, at 7:50 AM, Erik Sy wrote: > > Do you think the bullet point "There is a risk of rendering a site > unusable." does apply to DANE TLSA? No more so than with an expired certificate, or similar server operator negligence. -- Viktor. From nobody Tue Aug 27 14:20:19 2019 Return-Path: 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 1D74F12013B for ; Tue, 27 Aug 2019 14:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 xEONJniSBYQE for ; Tue, 27 Aug 2019 14:20:14 -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 96361120113 for ; Tue, 27 Aug 2019 14:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 5608925F for ; Tue, 27 Aug 2019 23:20:11 +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 4-WS-bpJ-JJM for ; Tue, 27 Aug 2019 23:20:10 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5799B.versanet.de [89.245.121.155]) (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 2A21E25E for ; Tue, 27 Aug 2019 23:20:08 +0200 (CEST) From: Erik Sy To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> 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: <4d468f3e-da2a-2586-bdf8-9235589202fa@informatik.uni-hamburg.de> Date: Tue, 27 Aug 2019 23:20:07 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000600040207040205050401" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:20:17 -0000 This is a cryptographically signed message in MIME format. --------------ms000600040207040205050401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi Eric and Viktor, On 8/25/19 22:40, Erik Sy wrote: > Here is a quote from Chris Palmer on this issue[1]: > > "The strength of PKP =E2=80=95 run-time enforcement with hard-fail =E2=80= =94 is also > exactly its weakness. Some people are OK with the risk, but overall I > think the market has spoken: HPKP has seen close to no adoption. People= > don't want to brick their sites. > > As for DANE, it would at best have the same strength/weakness of HPKP, > but with the additional problems of DNSSEC." > > In total, it seems like Chrome does not want to deploy DANE. > Erik > > 1: > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3= rZ8/eNMwKPmUBAAJ It seems to me, that both of you are OK with the risk of DNSSEC + DANE TLSA leading to hard failures. I share the view of Chris Palmer, that the security improvements of Public Key Pinning (PKP) in browsers are not worth the caused usability issues. I like to point out, that resolver-less DNS can be extended to support DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in case browser vendors decide to support DNSSEC + DANE TLSA the browsers can receive the corresponding records also via resolver-less DNS. Erik --------------ms000600040207040205050401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjcyMTIwMDdaMC8GCSqGSIb3DQEJBDEiBCCucWBDDA1n aZvlaplzHIg/inckDNJgrQDUE06NIB1RdjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQCUd0uf/vLkpP/jnMx1x30mmmY0JyJj9UgEvk1N YwmwYwaRoguCKD7V/TOAJU933x647r5kd0i0BGtbFzMevnsDngOz2Jt8EauFJtq4+FclqiSP wxYcFeUurjWs6bH/UtvscbD7v9l4/xhX11lfW7C1XrzQkJLBrNmQRwx7Z5FzBdCveP8eAq8x Y6bQA7c2JdUbms5Z4vB73uDkW/VuKLLQrh34XDHOsPlqoK6srSAvIwJvEklzber2jWI6iyVR 15rMGNw9tb/0L48UWNiKnvckaYq90TcrrBjJZyC3XXCYnP46RPp/liS7GuW1L78s669OpBKj YXYAFBu4vrJwRlyrAAAAAAAA --------------ms000600040207040205050401-- From nobody Tue Aug 27 14:39:54 2019 Return-Path: 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 CF734120113 for ; Tue, 27 Aug 2019 14:39:51 -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 tsWXh2wEjk2t for ; Tue, 27 Aug 2019 14:39:49 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8042812004D for ; Tue, 27 Aug 2019 14:39:49 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B3BAB3FC1F for ; Tue, 27 Aug 2019 17:39:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 27 Aug 2019 17:39:47 -0400 Content-Transfer-Encoding: 7bit Reply-To: resolverless-dns@ietf.org Message-Id: <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:39:52 -0000 > On Aug 27, 2019, at 5:18 PM, Erik Sy wrote: > > It seems to me, that both of you are OK with the risk of DNSSEC + DANE > TLSA leading to hard failures. I also deny beating my spouse... Seriously, the premise of the question "are you OK with the risk of DANE leading to hard failures" is flawed. Hard failures are the purpose of security mechanisms. Of course I am OK with a security mechanism that may deny access, that's not the right question. The right question is whether a given mechanism is sufficiently robust to be usable. HPKP fails that criterion, but DANE does not suffer the same design flaws. Like anything not yet widely deployed for years, DANE still requires some operator experience and improved tooling (monitoring and deployment) to further reduce opportunities for operator error, but there is no fundamental obstacle to robust DANE deployment as there was with HPKP, and DANE is already considerably more robust in practice. > I share the view of Chris Palmer, that > the security improvements of Public Key Pinning (PKP) in browsers are > not worth the caused usability issues. HPKP is irrelevant to the discussion. > I like to point out, that resolver-less DNS can be extended to support > DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in > case browser vendors decide to support DNSSEC + DANE TLSA the browsers > can receive the corresponding records also via resolver-less DNS. Actually, we've been down that road already (TLS DNSSEC chain extension fiasco). There is no clean way to provide downgrade resistance in such a protocol, or even properly ensure that answers are in bailiwick. I doubt you are proposing that servers MUST always return a full DNSSEC validation chain for the returned RRsets (or denial of existence proofs for the associated DS RRs). My take is that cache-poisoning-as-a-service is unlikely to be a good idea. -- Viktor. From nobody Thu Aug 29 07:36:51 2019 Return-Path: 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 352E712083B for ; Thu, 29 Aug 2019 07:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 Sb6iG0h0wyWV for ; Thu, 29 Aug 2019 07:36:47 -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 BACE812083A for ; Thu, 29 Aug 2019 07:36:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E66C05BA for ; Thu, 29 Aug 2019 16:36:44 +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 mPN9gKtKb0Nv for ; Thu, 29 Aug 2019 16:36:44 +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 C263E5B9 for ; Thu, 29 Aug 2019 16:36:43 +0200 (CEST) To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> From: Erik Sy 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: <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> Date: Thu, 29 Aug 2019 16:36:42 +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: <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020109000008020902090005" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:36:49 -0000 This is a cryptographically signed message in MIME format. --------------ms020109000008020902090005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 8/27/19 23:39, Viktor Dukhovni wrote: >> On Aug 27, 2019, at 5:18 PM, Erik Sy wrote: >> >> It seems to me, that both of you are OK with the risk of DNSSEC + DANE= >> TLSA leading to hard failures. > I also deny beating my spouse... Seriously, the premise of the questio= n > "are you OK with the risk of DANE leading to hard failures" is flawed. > Hard failures are the purpose of security mechanisms. Of course I am > OK with a security mechanism that may deny access, that's not the > right question. I disagree, that this question is flawed. It assumes that DNSSEC + DANE is an optional security mechanism in the context of web browsers. Note, that for example a valid TLS certificate is considered a mandatory security mechanism and should be enforced by hard failures. Thus, the question is more like "are you OK with optional security mechanisms leading to hard failures". > > The right question is whether a given mechanism is sufficiently robust > to be usable.=20 At least the given mechanism needs also to provide a significant security benefit. In my view, the additional benefit of DNSSEC+ DANE compared to Certificate Transparency + Strict Transport Security (HSTS or MTA-STS) is for the majority of server operators or users not relevant= =2E >> I like to point out, that resolver-less DNS can be extended to support= >> DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in= >> case browser vendors decide to support DNSSEC + DANE TLSA the browsers= >> can receive the corresponding records also via resolver-less DNS. > Actually, we've been down that road already (TLS DNSSEC chain > extension fiasco). There is no clean way to provide downgrade > resistance in such a protocol, or even properly ensure that > answers are in bailiwick. I doubt you are proposing that servers > MUST always return a full DNSSEC validation chain for the returned > RRsets (or denial of existence proofs for the associated DS RRs). In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes only sense if the server provides a full DNSSEC validation chain because everything else seems to introduce significant delays. However, given the significant size of full DNSSEC validation chains such feature should be deactivated in a default configuration of resolver-less DNS. Anyway, as long as no web browser intends to support a validation of DNS records via DNSSEC + DANE TLSA, there is no requirement for resolver-less DNS to support this practice. Erik --------------ms020109000008020902090005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjkxNDM2NDJaMC8GCSqGSIb3DQEJBDEiBCA7QuBcAUdF 4qWZx4t7BcSZMN4DGyAEPqNEqJczgNOgujBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQAPKOJdzguOVcyYPgZn25ovvDmlghGZJ1l4ybtS KtK9yP4AP2fgCi9QEVbonXMNwQpVywmzJhJs+WGjPdis2Kej4wKTKFUQv0hAa4/5kMkOyUiH fUzCYuzZt2g0EbrO/LZq+Fyb5uG3xdgnVHKzOkqmlsFAXrbn6pUQC1CPpISKYfjpxdl74HyD m/yTDX6lcB1iPrqUmWt0qa8WRnlgKfQ0MAhMUlU2EWFVd2+0ekPTyWoLaNZf14xoyizTQcZz ovG+xrAmNaqkSsRizmQg0oNR69671G5uCPBIxm5K9poMS51X3EABUTlx3L9cYTAWb8qgSLfj cSOSi8n4yc2FVaIBAAAAAAAA --------------ms020109000008020902090005-- From nobody Thu Aug 29 07:59:29 2019 Return-Path: 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 EB53B120119 for ; Thu, 29 Aug 2019 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 7s5VsYdY8G_6 for ; Thu, 29 Aug 2019 07:59:25 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4F61200F9 for ; Thu, 29 Aug 2019 07:59:25 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id w18so3241800qki.0 for ; Thu, 29 Aug 2019 07:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aPZiqjRt58IBgrPAR7z+lci5t55+OumBjJqJzwBfzlY=; b=NTFsBzpfv+px8Om2VqnokrozsIzbRn9ehaDNm7RUlArGpggy2txhYsRXZYiiHWltT2 zAjNsbv0tMkBqCgag+ezwOTlSv1Z6dzK1MkqQ7I2wblmO6hsmGPdwsDQv1Cvk7YVCB5b O91jjMoJMIi5bVTtfa02G1ojGYRkxEfj4uiJ+of0pvG1fJhdL01XyXsXYs81lRZENZsR jfXg3nyhm+HATGR+AXFfMeyKJjhHYRQG6ZSKVgbLw2UwKbRVF5veElEUi6Lazup0jVF+ kzsfFxRZb6x5UVindl4IsiXKVmWfNSBMEax6oxbR+9EyUypqXuZ7KZOyexVI62guOXBt OuJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aPZiqjRt58IBgrPAR7z+lci5t55+OumBjJqJzwBfzlY=; b=RzzN6sL940sagecr1op5Q6uYn590ofggY1nZ9x2Y/XMgIN6H00SsHdndn/c7CrWjU2 WfCg3A6yQF6Y2KTAcH74xexDamC+qLo5JBpGQ7W7UUkpg5psdweK9GzQcvYC9O327yi3 EdP51aThU45d19ymKcc53eFSUuqX6tb6U4XN25BTD0lPbbQrXNGPrxbPugqtGVTUS+uM by9sKkYeMqOWIavNpRyB7DLEzqnZI4saKBCjAROn/0RPBGYk+2c10TSjmz+8humKHv42 nFkaXzaBJ58v38HPuQpDYdr8JDu+p9V50xSmG5nQU46HdgnQsITPds4oABBiaXxDpiP5 lXnw== X-Gm-Message-State: APjAAAUXprF9VsuLBioXRJC2jME/xAfJ6AAjuETBbxxTj016VGJy62J+ GNw29r4qzmn5aJXyBpq8neyz4w== X-Google-Smtp-Source: APXvYqzMCxRaGJirh29pvVSxYPUgFIjWBco0asrmBXHirRIHxZxxj+r84ZsUhoJ6eA8v6whSx0R8OA== X-Received: by 2002:a37:a0c2:: with SMTP id j185mr9749291qke.123.1567090764379; Thu, 29 Aug 2019 07:59:24 -0700 (PDT) Received: from [10.0.100.59] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b50sm290271qte.48.2019.08.29.07.59.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 07:59:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) From: Ted Lemon In-Reply-To: <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> Date: Thu, 29 Aug 2019 10:59:22 -0400 Cc: resolverless-dns@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> To: Erik Sy X-Mailer: Apple Mail (2.3578.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:59:28 -0000 Or, the client could explicitly request the validation chain. But of = course this has implications for padding: it may be that the size of the = output will be more helpful for guessing. Or it may be that it makes = no difference, because the bulk of the data is signatures, which are in = principle always the same size (assuming that the client specifies the = signature algorithm it wants, and the server sends only those = signatures). This would be an interesting thing to investigate. > On Aug 29, 2019, at 10:36 AM, Erik Sy = wrote: >=20 > On 8/27/19 23:39, Viktor Dukhovni wrote: >>> On Aug 27, 2019, at 5:18 PM, Erik Sy wrote: >>>=20 >>> It seems to me, that both of you are OK with the risk of DNSSEC + = DANE >>> TLSA leading to hard failures. >> I also deny beating my spouse... Seriously, the premise of the = question >> "are you OK with the risk of DANE leading to hard failures" is = flawed. >> Hard failures are the purpose of security mechanisms. Of course I am >> OK with a security mechanism that may deny access, that's not the >> right question. >=20 > I disagree, that this question is flawed. It assumes that DNSSEC + = DANE > is an optional security mechanism in the context of web browsers. = Note, > that for example a valid TLS certificate is considered a mandatory > security mechanism and should be enforced by hard failures. Thus, the > question is more like "are you OK with optional security mechanisms > leading to hard failures". >=20 >>=20 >> The right question is whether a given mechanism is sufficiently = robust >> to be usable.=20 > At least the given mechanism needs also to provide a significant > security benefit. In my view, the additional benefit of DNSSEC+ DANE > compared to Certificate Transparency + Strict Transport Security (HSTS > or MTA-STS) is for the majority of server operators or users not = relevant. >>> I like to point out, that resolver-less DNS can be extended to = support >>> DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, = in >>> case browser vendors decide to support DNSSEC + DANE TLSA the = browsers >>> can receive the corresponding records also via resolver-less DNS. >> Actually, we've been down that road already (TLS DNSSEC chain >> extension fiasco). There is no clean way to provide downgrade >> resistance in such a protocol, or even properly ensure that >> answers are in bailiwick. I doubt you are proposing that servers >> MUST always return a full DNSSEC validation chain for the returned >> RRsets (or denial of existence proofs for the associated DS RRs). >=20 > In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes > only sense if the server provides a full DNSSEC validation chain = because > everything else seems to introduce significant delays. However, given > the significant size of full DNSSEC validation chains such feature > should be deactivated in a default configuration of resolver-less DNS. > Anyway, as long as no web browser intends to support a validation of = DNS > records via DNSSEC + DANE TLSA, there is no requirement for > resolver-less DNS to support this practice. >=20 > Erik >=20 >=20 > --=20 > Resolverless-dns mailing list > Resolverless-dns@ietf.org > https://www.ietf.org/mailman/listinfo/resolverless-dns From nobody Thu Aug 29 08:34:49 2019 Return-Path: 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 C027A1208B1 for ; Thu, 29 Aug 2019 08:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 V2cwzAcgAUAP for ; Thu, 29 Aug 2019 08:34:45 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41631208AD for ; Thu, 29 Aug 2019 08:34:44 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 1AF884C874 for ; Thu, 29 Aug 2019 11:34:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> Date: Thu, 29 Aug 2019 11:34:42 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: resolverless-dns@ietf.org Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> To: resolverless-dns@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 15:34:47 -0000 > On Aug 29, 2019, at 10:36 AM, Erik Sy = wrote: >=20 > On 8/27/19 23:39, Viktor Dukhovni wrote: >> Of course I am OK with a security mechanism that may deny access, >> that's not the right question. >=20 > I disagree, that this question is flawed. It assumes that DNSSEC + = DANE > is an optional security mechanism in the context of web browsers. Do or don't, there is no "try". Optional security mechanisms are largely pointless. Presently browsers don't support DANE, some day they may. In any case, the issue at hand is DNS(SEC) bypass, not DANE. Resolver-less DNS as proposed disregards long-standing defenses against address forgery by third parties, breaks geo load-balancing, breaks local filters that protect networks against known bad actors, and IDS systems that detect compromised nodes. It introduce a new cache-poisoning channel, and surprising differences between the IP addresses a browser might use to reach a site from cold start vs. after visiting some unrelated site. In the case of IPv6 it can be used to fingerprint and track clients by giving them ephemeral client-specific addresses (in the server's /64 or broader prefix) for third-party servers, and then proxying their connections (at layer 4) to the real server, while tracking the client's access to each site. =20 > At least the given mechanism needs also to provide a significant > security benefit. In my view, the additional benefit of DNSSEC+ DANE > compared to Certificate Transparency + Strict Transport Security (HSTS > or MTA-STS) is for the majority of server operators or users not = relevant. Let's not mix up HTTP and MTA-to-MTA SMTP. In SMTP, DANE has = significantly broader deployment (protected domains) than MTA-STS. The latter covers = more users of the big three centralized free email providers, but I am not a = fan of over-centralization of the Internet, and prefer open federated = architectures. > In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes > only sense if the server provides a full DNSSEC validation chain = because > everything else seems to introduce significant delays. In any case, the issue at hand is DNS, not DANE. A client that wants = TLSA records is not going to obtain them via resolver-less DNS, which IIRC is just about IP addresses. --=20 Viktor. From nobody Thu Aug 29 14:28:22 2019 Return-Path: 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 7A4E2120073 for ; Thu, 29 Aug 2019 14:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 2UrzLw2JHI-N for ; Thu, 29 Aug 2019 14:28:17 -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 98B43120C1B for ; Thu, 29 Aug 2019 14:28:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 6FE17406 for ; Thu, 29 Aug 2019 23:28:15 +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 jlDsYplx8Bal for ; Thu, 29 Aug 2019 23:28:15 +0200 (CEST) Received: from users-MBP.fritz.box (i59F574B4.versanet.de [89.245.116.180]) (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 8F8EB405 for ; Thu, 29 Aug 2019 23:28:14 +0200 (CEST) To: resolverless-dns@ietf.org References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> From: Erik Sy 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: <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> Date: Thu, 29 Aug 2019 23:28:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080207090608030800010502" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 21:28:21 -0000 This is a cryptographically signed message in MIME format. --------------ms080207090608030800010502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 8/29/19 17:34, Viktor Dukhovni wrote: > Resolver-less DNS as proposed disregards long-standing defenses > against address forgery by third parties, Can you please explain this point? > breaks geo load-balancing, No, there are no new issues with geo load-balancing compared to using a public DNS resolver. > breaks local filters that protect networks against known bad actors, > and IDS systems that detect compromised nodes. If you think there are any new issues compared to using a public DNS resolver, I would appreciate you explaining these points. > > It introduce a new cache-poisoning channel, and surprising differences > between the IP addresses a browser might use to reach a site from cold > start vs. after visiting some unrelated site. Also traditional DNS resolvers are vulnerable to cache-poisoning attacks.= > > In the case of IPv6 it can be used to fingerprint and track clients by > giving them ephemeral client-specific addresses (in the server's /64 > or broader prefix) for third-party servers, and then proxying their > connections (at layer 4) to the real server, while tracking the > client's access to each site. This tracking mechanism is also feasible using traditional DNS. >> At least the given mechanism needs also to provide a significant >> security benefit. In my view, the additional benefit of DNSSEC+ DANE >> compared to Certificate Transparency + Strict Transport Security (HSTS= >> or MTA-STS) is for the majority of server operators or users not relev= ant. > Let's not mix up HTTP and MTA-to-MTA SMTP. In SMTP, DANE has significa= ntly > broader deployment (protected domains) than MTA-STS. Please note that MTA-STS is still a very young protocol. >> In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes >> only sense if the server provides a full DNSSEC validation chain becau= se >> everything else seems to introduce significant delays. > In any case, the issue at hand is DNS, not DANE. A client that wants T= LSA > records is not going to obtain them via resolver-less DNS, which IIRC i= s > just about IP addresses. Resolver-less DNS is also concerned about the validation of the obtained DNS records. Independently, of DANE TLSA which Chromes does not intend to support there is still a security benefit of using DNSSEC to validate the integrity of the received DNS records. If it is technically feasible to integrate a DNSSEC validation in resolver-less DNS, then this sounds like a good idea to me. Erik --------------ms080207090608030800010502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ERMwggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ 0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUkP7agCwf9 TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22MZD08 WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAd BgNVHQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK 4OpL4qIMz+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYB BQUHAQEEgdAwgc0wMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1T ZXJ2ZXIvT0NTUDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1nMi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21 rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCNT1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7L n8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+lgQCXISoKTlslPwQkgZ7nu7YRrQb tQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v9NsH1VuEGMGpuEvObJAaguS5 Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7EUkp2KgtdRXYShjqFu9V NCIaE40GMIIGSTCCBTGgAwIBAgIMIQHY9Rd/LjLmRiJpMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRz Y2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQD DBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDUyMDA3NDY1NVoXDTIyMDUx OTA3NDY1NVowgboxCzAJBgNVBAYTAkRFMRAwDgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdI YW1idXJnMR0wGwYDVQQKDBRVbml2ZXJzaXRhZXQgSGFtYnVyZzEWMBQGA1UECwwNTUlOLUZh a3VsdGFldDEfMB0GA1UECwwWRmFjaGJlcmVpY2ggSW5mb3JtYXRpazEdMBsGA1UECwwUUHJp dmFjeSBhbmQgU2VjdXJpdHkxEDAOBgNVBAMMB0VyaWsgU3kwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDOmt+wTZzbmaWgSPfSeGvjerL2xZdYxANWai8LQl7ABkOtrvHLUmD5 q/j8acxtQDUrnrknDd7yqgIcKmw4ciODoivseVRuj9DTFz2DNRPHOWUR4AMc5bS4+nUH0kZu OlY3dHI40khvkiy27+rZAJKDDE6D67CaE/oz6EMVC9f/jN5Y+PXIQUuxZqWdB0Pz1GUMipcI CUNxwddJ8zzX/JrqMTLHlQrYp8Jfjhk0a7uYs7TIlCy4d9gbpXdiArilrPxppYQUhKuh+T6/ yJNqdHRMRbJIR5Y6wHhkQ/QYAEbkauKbCpXI86nZDNac1XzLiDty6zV1P+rYZt9vpCfXj/q9 AgMBAAGjggJ4MIICdDA+BgNVHSAENzA1MA8GDSsGAQQBga0hgiwBAQQwEAYOKwYBBAGBrSGC LAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ0eQee83dHDM0XFIlMDYlz WtQAEDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBKBgNVHREEQzBBgRxzeUBp bmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlgSFlcmlrLnN5QGluZm9ybWF0aWsudW5pLWhhbWJ1 cmcuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsGAQUFBwEB BIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVy L09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2Jh bC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQELBQADggEBAD1adVYbchk1itDMH521NZM0kjs1+P+qlWk7HOKMHqWO9+acCqmSO9wp PPxxBzvPAHFBwpoMTz1w33zDOIHYKx/zWWE58NkBKy85RGO9jxvhd6M4gIOIBUhNqKo74Yyc 4Sm3roa+biWbVMN7lfkdnFNEWeNoT+kYDWmLs+rQwABnX7BS1FZLCwZagfkuWvy5J1C0Jlqz Z79uWEnnhh80KGKReaWtIeK6CFqgO147ro4riBQxr3MzlHQQXxH3AV9G0DTxBlx/zBxpR+bE YwXE8WVEVoexhETFyKEbMiEUnkMY4KzvKW1pv30ojUgaQq/j1yWr+jLyvud1ynl0a9+s29kx ggQLMIIEBwIBATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIQHY 9Rd/LjLmRiJpMA0GCWCGSAFlAwQCAQUAoIICPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA4MjkyMTI4MTNaMC8GCSqGSIb3DQEJBDEiBCCFCwHJ5ORO lcVIyDImp/kVZMY0YC7Q7Bf10TNz9wR7+TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGvBgkrBgEEAYI3EAQxgaEwgZ4wgY0xCzAJ BgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNj aGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsMB0RGTi1QS0kxJTAjBgNVBAMM HERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUXfy4y5kYiaTCBsQYLKoZIhvcN AQkQAgsxgaGggZ4wgY0xCzAJBgNVBAYTAkRFMUUwQwYDVQQKDDxWZXJlaW4genVyIEZvZXJk ZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsM B0RGTi1QS0kxJTAjBgNVBAMMHERGTi1WZXJlaW4gR2xvYmFsIElzc3VpbmcgQ0ECDCEB2PUX fy4y5kYiaTANBgkqhkiG9w0BAQEFAASCAQBpHg8paKEiZEQkET3FxKpRA7A7AHdh1C7MgKKI Voxohpe/SgMtGn2dmWDkMA65QYZD7zkeHf4tpEayWvQjKvZZRbHtZGwuiguXRiV4qmSGJNat SOPHjNZWRCcqUjdy/1mrKwHHkOloSRXGZtbRPaQheEtBZxdqI48PCJydpWxoiC9PTjce6We5 I2bftFr1TzGbngr5dM1H9a9Mv6r4XzFT8lSA9Metm1KgEUZQQayEbYBRGBNgqGteR+7aZQ+J PFVuSi6Kdl/V1nYbod3/NKfVowHyMprv9+BSIDxMnLZvm4KE7KgBCiwCpk1WcmHD6DhTqEPy pMghsJUESFd65tpiAAAAAAAA --------------ms080207090608030800010502-- From nobody Thu Aug 29 15:15:58 2019 Return-Path: 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 F3AAD120C1B for ; Thu, 29 Aug 2019 15:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 TxNxkBttozsV for ; Thu, 29 Aug 2019 15:15:54 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49E51200A3 for ; Thu, 29 Aug 2019 15:15:54 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id g2so3075607pfq.0 for ; Thu, 29 Aug 2019 15:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SNc8L3HvN3sstWqtBdiBWwkhvBUNf3WmSEgu1vVbOJU=; b=T+PzbYPX7H0kFnxxyES1Y7zw6eoqw32FDox+/peaS9aHQTstrU0bdz9vLMzsnsAD4h I4DAfjYy2ud60DRKgTl0O1LskVWUxzoVupx9WR3I6nO6hBYAqoQBzvofmzT1KkvfVAQ7 Z795ct2LofhthRtT/1wcWf/KeCImZ/ZIWH2P4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SNc8L3HvN3sstWqtBdiBWwkhvBUNf3WmSEgu1vVbOJU=; b=D4tzvi/PahVdbIEAT7hzB2yvAiETcIAEF1z11HyQYdH7T2hYaRcVIQTrHB0e7AVPDM 0Wrd/KjtjQ58cpew1u3x0PoHhqrHhcgF1A4d3nspnrpHuFiGyMfiTJ7o3ZndYsZ9I70g n5bVmm/WxZSE3QdFMW+kjcuoDggw9x6vvCx7iw4IHKJgbxUQZI89ThNZzNxL7zL/wiKh mv1EhQUxlr+xl/FewxxmJuXySkhH3GPujU65FE0X0fMle9Y+OSkEX2PWt5z6VF1fo0oK 8ULfCf3JdkwjueRDb4ivVwaL/wzYbEoU25HMHl5CNl1axOT6fs8+Qm8idtAk3o4s6Lji HEzw== X-Gm-Message-State: APjAAAUGY18oSfrTPXXfW+e3c7bUxI9LrKvyimozI3gXXLv7UWrk//F4 /sx9YDCU/1sdhiOFG/gFj9fwcPzlnHgeVw== X-Google-Smtp-Source: APXvYqy2RIWzgyBHWzWj+tJsVkLkIbRSeOd1BuMWDNeXlExTpP7CJXrXPO/joRzYBEdsEeoQRmZz5g== X-Received: by 2002:a63:1507:: with SMTP id v7mr94100pgl.397.1567116953415; Thu, 29 Aug 2019 15:15:53 -0700 (PDT) Received: from [25.171.177.25] ([172.58.27.9]) by smtp.gmail.com with ESMTPSA id j1sm3877797pfh.174.2019.08.29.15.15.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 15:15:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (16G102) In-Reply-To: <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> Date: Thu, 29 Aug 2019 18:15:49 -0400 Cc: resolverless-dns@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F173B85-D52F-46F8-90A3-24F7FF59E234@hopcount.ca> References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 22:15:57 -0000 Hi Erik, On Aug 29, 2019, at 17:28, Erik Sy wrote: > On 8/29/19 17:34, Viktor Dukhovni wrote: >> breaks geo load-balancing, > No, there are no new issues with geo load-balancing compared to using a > public DNS resolver. I am usually pretty wary of absolute statements, especially those that decla= re the absence of something. I haven't seen a comparative security assessmen= t of both (and it surely depends on precisely what model of resolverless DNS= you mean), though, so I will not take a side in the entertaining debate tha= t seems likely to result from that. However, I do think it's also worth pointing out that geo load-balancing usi= ng the DNS today is already a terrible mess and it will be a joyous day when= it can be replaced by something less bad. (soapbox noises) The general process by which a DNS server responds to a query for a (name, c= lass, type) tuple that is configured with geo-specific answers is to process= a set of rules at query time, consulting general-purpose databases maintain= ed at the DNS edge that map an address to something like a (provider, city) p= air, and then doing additional database lookups to determine the response th= at should be sent to the client for the particular service whose name (one o= f whose names) the client is looking up. The complexity of the code at the DNS edge is significant, and significant f= ailures have been observed. In an enterprise DNS provider, the code that doe= s this stuff is often not available for public review, since it constitutes s= ecret sauce that tastes of competitive advantage. This stuff is really hard t= o do without failure and introducing customer-enraging latency; it's not unr= easonable that people try to protect their investment. Centralised resolvers need to make use of the EDNS0 client-subnet option in o= rder to allow the user's real location to be exposed to the server that is g= eo-answering. The EDNS0 client-subnet option has unintended consequences (se= e David Dagon's recent descriptions). The database that maps addresses to (provider, city) pairs is either frequen= tly inaccurate (watch *NOG lists for pleas for help from operators whose cus= tomers are being served from nodes far away) or is accurate because it is ma= intained by mining other data sources. If you have a really broad anycast ne= twork you might be able to imagine doing this based on routing and answering= node location; for everybody else those data sources are real user monitori= ng scripts running in browsers on not-obviously-related web sites, all perfo= rming performance measurements and centralising the results without the user= s of those stooge web sites necessarily being aware, or at least being given= the option to opt-in. Complicated web services, perhaps especially those with complex UX, use all o= f these techniques together with a litany of short-lived, non-repeated DNS n= ames intended to customise and optimise the performance for the end-user. Th= e end result in some networks has been the observation that these short-live= d names consitute such a high proportion of cached data (e.g. in campus reso= lvers) that "we don't have the RAM to handle another Facebook". Some big access providers configure resolvers with hundreds of exit addresse= s so that they will source queries for particular names towards enterprise D= NS servers from dedicated sources, as a workaround for when the geo-ip on th= e server is known to fail. This might seem like a ridiculous optimisation un= til you appreciate that your entire network's capacity planning might depend= on decisions being made by CDNs and enterprise DNS providers, and anything y= ou can do to avoid mistakes in those third-party systems is another week you= get to keep your customers. In short, the status quo is extremely slippery, architecturally messy, frequ= ently non-deterministic and high-overhead, one that has been observed to put= the burden of performance measurement and reporting on unrelated third-part= y Internet users, chasing an end-result that is often still not doing a very= good job. As far as DNS geo-mapping for the purposes of content steering today is conc= erned, the only way is up. Rearchitecting the whole enterprise DNS and CDN industries is a task on a sc= ale larger than moving from IPv4 to IPv6. However, what we *can* do is take s= pecific components of the problem space and find more-elegant solutions. It s= eems to me that resolverless DNS has the potential to be one of those. The s= tatus quo here is almost not worth defending; some kind of change is needed.= Joe= From nobody Thu Aug 29 15:51:49 2019 Return-Path: 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 56268120089 for ; Thu, 29 Aug 2019 15:51:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mOBA_mpWD_eB for ; Thu, 29 Aug 2019 15:51:46 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCB4120059 for ; Thu, 29 Aug 2019 15:51:45 -0700 (PDT) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 78D54892E8 for ; Thu, 29 Aug 2019 22:51:44 +0000 (UTC) From: Paul Vixie To: resolverless-dns@ietf.org Date: Thu, 29 Aug 2019 22:51:42 +0000 Message-ID: <1995583.25VvvpjhRo@linux-9daj> Organization: none In-Reply-To: <4F173B85-D52F-46F8-90A3-24F7FF59E234@hopcount.ca> References: <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> <4F173B85-D52F-46F8-90A3-24F7FF59E234@hopcount.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2830527.3NLNfHCMlE" Content-Transfer-Encoding: 7Bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 22:51:47 -0000 This is a multi-part message in MIME format. --nextPart2830527.3NLNfHCMlE Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, 29 August 2019 22:15:49 UTC Joe Abley wrote: > ... > > ..., I do think it's also worth pointing out that geo load-balancing > using the DNS today is already a terrible mess and it will be a joyous day > when it can be replaced by something less bad. > > ... see also: _What DNS Is Not_, Paul Vixie, Internet Systems Consortium ACM Queue; Volume 7, Issue 10; November 5, 2009 https://queue.acm.org/detail.cfm?id=1647302[1] -- Vixie -------- [1] https://queue.acm.org/detail.cfm?id=1647302 --nextPart2830527.3NLNfHCMlE Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, 29 August 2019 22:15:49 UTC Joe Abley wrote:

> ...

>

> ..., I do think it's also worth pointing out that geo load-balancing

> using the DNS today is already a terrible mess and it will be a joyous day

> when it can be replaced by something less bad.

>

> ...

 

see also:

 

_What DNS Is Not_, Paul Vixie, Internet Systems Consortium

ACM Queue; Volume 7, Issue 10; November 5, 2009

https://queue.acm.org/detail.cfm?id=1647302

 

--

Vixie

--nextPart2830527.3NLNfHCMlE-- From nobody Thu Aug 29 22:30:28 2019 Return-Path: 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 25F89120113 for ; Thu, 29 Aug 2019 22:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 r_B5rXuABUpH for ; Thu, 29 Aug 2019 22:30:24 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB901200E3 for ; Thu, 29 Aug 2019 22:30:24 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 6D185725C1; Fri, 30 Aug 2019 01:30:23 -0400 (EDT) Date: Fri, 30 Aug 2019 01:30:23 -0400 From: Viktor Dukhovni To: resolverless-dns@ietf.org Message-ID: <20190830053023.GE90696@straasha.imrryr.org> Reply-To: resolverless-dns@ietf.org References: <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 05:30:27 -0000 On Thu, Aug 29, 2019 at 11:28:13PM +0200, Erik Sy wrote: > On 8/29/19 17:34, Viktor Dukhovni wrote: > > Resolver-less DNS as proposed disregards long-standing defenses > > against address forgery by third parties, > > Can you please explain this point? IIRC the protocol allows any authenticated server (with Let's Encrypt, that's everybody) to return "out-of-bailiwick" answers (for any unrelated domain). Yes, a client's designated resolver can also do that, but some clients perform local DNSSEC validation, and in any case there's a big difference between trusting name resolution to a set of dedicated resolvers, vs. each and every server one happens to visit (by clicking on a malicious link for example). > > breaks geo load-balancing, > > No, there are no new issues with geo load-balancing compared to using a > public DNS resolver. Well, the public DNS resolvers (which I do not use on my network) typically pass an EDNS0 client-subnet option to the upstream authoritative server. I don't recall anything similar in the paper. But if we're doing away with geo load-balancing, and moving to only using anycast IPs to reduce latency, that's fine by me, there are other more important problems. > > breaks local filters that protect networks against known bad actors, > > and IDS systems that detect compromised nodes. > > If you think there are any new issues compared to using a public DNS > resolver, I would appreciate you explaining these points. There are a lot more resolvers than the public DNS resolvers that you seem to expect the whole world to be using. The resolvers at the office and on my home network are local, I don't use "public DNS resolvers". > > It introduce a new cache-poisoning channel, and surprising differences > > between the IP addresses a browser might use to reach a site from cold > > start vs. after visiting some unrelated site. > > Also traditional DNS resolvers are vulnerable to cache-poisoning attacks. Not with DNSSEC validation, and modestly difficult off-path. But with this proposal, you get cache poisoing by design from any off-path server the client happens to visit. > > In the case of IPv6 it can be used to fingerprint and track clients by > > giving them ephemeral client-specific addresses (in the server's /64 > > or broader prefix) for third-party servers, and then proxying their > > connections (at layer 4) to the real server, while tracking the > > client's access to each site. > > This tracking mechanism is also feasible using traditional DNS. But not available to every off-path server I visit. My resolver does not do that. Your proposal would delegate this ability to every random server I visit. That's a security fail. > >> At least the given mechanism needs also to provide a significant > >> security benefit. In my view, the additional benefit of DNSSEC+ DANE > >> compared to Certificate Transparency + Strict Transport Security (HSTS > >> or MTA-STS) is for the majority of server operators or users not relevant. > > Let's not mix up HTTP and MTA-to-MTA SMTP. In SMTP, DANE has significantly > > broader deployment (protected domains) than MTA-STS. > > Please note that MTA-STS is still a very young protocol. It is not getting much support from either Exim or Postfix, any time soon it is mostly a cloud-provider <-> cloud-provider walled garden. If you like your mail centralized and mined for targetted ads, use email from these providers and MTA-STS. But again the issues with resolverless DNS (for web browsers) are unrelated to DANE vs. MTA-STS for MTA-to-MTA SMTP, or even DANE for the web. DANE and PKIX are concerned with peer authentication, not integrity of IP address records, and modulo traffic analysis provide a secure channel even if layers 1 through 4 are compromised by the attacker. -- Viktor. From nobody Sat Aug 31 12:11:32 2019 Return-Path: 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 96534120122 for ; Sat, 31 Aug 2019 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 N1Wf-ec1qNul for ; Sat, 31 Aug 2019 12:11:20 -0700 (PDT) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E120120132 for ; Sat, 31 Aug 2019 12:11:20 -0700 (PDT) Received: by mail-qt1-f179.google.com with SMTP id z4so11417881qtc.3 for ; Sat, 31 Aug 2019 12:11:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Ak+kaP74xpDK6D0IRaV9u6WNroDjS1Ve7Ay1rhv64o=; b=rAKAG8wnKeuOr1ldQIOJWQmVoP2gSoiGBnHqOf9L8ynaOYW1ydegUwBZcfwD/M4U1S tHskVyTGwIgta8cRnX1ZYBHc79xw3KWpOIvbHp1/q5CO3iFMZX3OocJyZ/NHm8gOqyYT uSLQ3NzCq8r+od2FGPb9OhtHbRxIVsPSnlr7nakJ1QFAzQaUe39rK3nYydz2tO2P6RoR tyVPivHUMvA4FQmhFA3DN/+RY8WdqKpV2tOe+5Xo8LviSC9kLVezaKpA+BYbBljfrZrt S9ccFZBXTruVXlsmYHFiadPEzNl0VULOwhca8Us4LgatQzMg8t6DBZDizE3Ab8g02YyQ bxcQ== X-Gm-Message-State: APjAAAXZEZe1HHXsd4nmypTeLDqZoG/mrzGJEnIWU4GJZbjtCgDkaL0P qtW3xpWcXeXooGiyjxJaUZGaOKdqA1I= X-Google-Smtp-Source: APXvYqz5VbyIaHaLC0NdPacwzuBTSdCyz2NxSfZ0WWO7s+uUIqGfEPv6c5LkoBBGLrq8ZIY6GHhJlA== X-Received: by 2002:a0c:fd91:: with SMTP id p17mr14193035qvr.170.1567278679073; Sat, 31 Aug 2019 12:11:19 -0700 (PDT) Received: from [10.159.78.32] ([129.174.182.32]) by smtp.gmail.com with ESMTPSA id h137sm4237664qke.51.2019.08.31.12.11.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Aug 2019 12:11:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Eric Osterweil In-Reply-To: <4d468f3e-da2a-2586-bdf8-9235589202fa@informatik.uni-hamburg.de> Date: Sat, 31 Aug 2019 15:11:17 -0400 Cc: resolverless-dns@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4568720.uvMTqBdgP4@linux-9daj> <34813218.VKkrhzyXsx@linux-9daj> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <4d468f3e-da2a-2586-bdf8-9235589202fa@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 19:11:30 -0000 Jumping back to this (focusing on just DNSSEC for a moment): > On Aug 27, 2019, at 5:20 PM, Erik Sy = wrote: >=20 > Hi Eric and Viktor, >=20 > On 8/25/19 22:40, Erik Sy wrote: >> Here is a quote from Chris Palmer on this issue[1]: >>=20 >> "The strength of PKP =E2=80=95 run-time enforcement with hard-fail = =E2=80=94 is also >> exactly its weakness. Some people are OK with the risk, but overall I >> think the market has spoken: HPKP has seen close to no adoption. = People >> don't want to brick their sites. >>=20 >> As for DANE, it would at best have the same strength/weakness of = HPKP, >> but with the additional problems of DNSSEC." >>=20 >> In total, it seems like Chrome does not want to deploy DANE. >> Erik >>=20 >> 1: >> = https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8= /eNMwKPmUBAAJ >=20 > It seems to me, that both of you are OK with the risk of DNSSEC + DANE > TLSA leading to hard failures. I share the view of Chris Palmer, that > the security improvements of Public Key Pinning (PKP) in browsers are > not worth the caused usability issues. Here=E2=80=99s a quote (and write-up) from Geoff Huston: ``Failing to secure DNS is 'savage ignorance=E2=80=99=E2=80=99' = - = https://www.zdnet.com/article/failing-to-secure-dns-is-savage-ignorance-ge= off-huston/ ymmv ;) >=20 > I like to point out, that resolver-less DNS can be extended to support > DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in > case browser vendors decide to support DNSSEC + DANE TLSA the browsers > can receive the corresponding records also via resolver-less DNS. To be a little more blunt (or maybe not): I think it=E2=80=99s false = logic to treat this as a choice for new protocol development. DNS is an infrastructure protocol. In it, authorities and resolvers = _both_ play a role (through their stated/deployed security postures) in = how they want security to be enforced. DNS' security extensions are = part of how rightful resource holders (authoritative zones) express = their desire and intent to secure their resources, separately from how = resolvers verify security. It seems to me to be poor engineering if a = newer protocol encourages resolvers to ignore authorities' stated desire = for security. I=E2=80=99d posit that newer protocols that intend to = _interoperate_ with the DNS can only correctly do so by conforming with = that protocol=E2=80=99s specification (and those of its standards-track = extensions), of which DNSSEC is one. That is what protocols are for: = interoperation of heterogeneous implementations/systems. The idea that = cherry-picking which part of DNS a new protocol suite wants to embrace = is a suspicious approach to engineering protocols, imho. Eric=