[DNSOP] Solution to bootstrap broblem in RFC8310?

Alexander Koeppe <format_c@online.de> Sun, 11 November 2018 00:07 UTC

Return-Path: <format_c@online.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ADB127148 for <dnsop@ietfa.amsl.com>; Sat, 10 Nov 2018 16:07:57 -0800 (PST)
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] 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 lZkFMQrbVCAB for <dnsop@ietfa.amsl.com>; Sat, 10 Nov 2018 16:07:55 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (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 CC459127133 for <dnsop@ietf.org>; Sat, 10 Nov 2018 16:07:54 -0800 (PST)
Received: from [172.21.21.53] ([213.188.106.104]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MKKER-1g4FfD0pAN-00LjJc for <dnsop@ietf.org>; Sun, 11 Nov 2018 01:07:52 +0100
To: dnsop@ietf.org
From: Alexander Koeppe <format_c@online.de>
Message-ID: <6b6a5a7c-107b-2595-27c5-b3d4cc4d6f04@online.de>
Date: Sun, 11 Nov 2018 01:07:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: de-CH
X-Provags-ID: V03:K1:f3TkAKI8KtL8E1jgQgDFc/bZtD3bgaiydXFrEZZSpOrY++7P5JR juGJKjfb4f2xQMBegnfR6lvM/uzeKTrT6oGg5XUWgwWFEqZC96KvLXmG59y6FKE0+Pol3c8 0ybJl0bfaCjmviNEIg3mhK7SfZqPWBAHyaSytZ6iJE+Zr0L8sqbnd0qTQu1q9NAJnFL28ts c3SzdFdy8oUZeLdV2PRtg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:osa8MWsDB94=:aqtuYMdTIytp0sFUBJivky aX2bLKvr5f8mX/76lv90UKDO811E03dgCVkiOyaZG1yX72xy/ShQH/cgWp+tTvNjPDKAhWAwQ vTDN7RskkACqBcP1kd0zbBqpxqrB/4CFW7e5SOMXTPCNmYn6C2eWOlC8uuCbeiavYy/IcIUpX o/1Z8k771t6vwX6YJIrIp+Tflr28iBUFapkzzVJJ0i5AaeQgGJSPwPDxaJvlhKc3AtFWHbzL7 54GaWCs5DO0wlY5Cq/eus9E4+2yiUCc9Sl+p7fn+alBshxKx1ZmCp6KTLSdD2kLMsbVgAG2Yv V/NUf+Z3posata7vj6I1Dh4v4RUQh8Zif83qt8h1Ez5Hk89ciqtLkaCrBkbvUxkLFM0g9gRxy KXkYfgWyYaFDcPp+U4EUzk3FqgfbPHdXUGNDYBQA0Lf/iottxYlk/bP8YVjvlZCduTrE3wrAx nF5blAZxcrO/WyShh7+LMdAUekasY+pJIfnAW1dDArc/cqSJYK8yX1FEi5WJrTFftv7BgTWBe hnxSXySXi6KifYProx7wd3dJu87wsH7IGXZ5lcwtL9ztHDWCCWsEadXeFDxP+wFCeyWbtVN+X el/cDMGyRO5jw5rr/NyzPEuRmib+7L2Xwho6pyIkRglTAglbMKJYIEDcGR9Yrwpa2qppy9gpr DBE5xJA8Uqbhid/PxEU1BJUwGDrmDlWMZXsDLFmCxekEpJmvtIO1EGt8NyHt3UyYgGZRGOy0y lgQ/5IJ4/5pFgE6r8Rc2rcQZWwDBo+uzVT9OWBk8nvsjEqVGK8JTuu+2Il+gIjfEZenCpnueL /CFKcr/aEBtZMWTf9LJZmGYL/DxNg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pogEpZbovS8TTORDklYcEoT_SJk>
X-Mailman-Approved-At: Sat, 10 Nov 2018 17:06:44 -0800
Subject: [DNSOP] Solution to bootstrap broblem in RFC8310?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Nov 2018 00:08:42 -0000

Hello,

I've just read the RFCs for DNS over TLS (RFC7858 + RFC8310) and DNS
over HTTPS (RFC8484) because I'd like to understand the fuzz of the
latest discussions around these topics.

In my conclusion, the concept behind DoH doesn't go down well for me at
all. It's appearing to me like fiddeling as a whole to get it somewhat
working.

However both approaches have a chicken-egg problem. While DoT need to
somewhat know the ADN for a given DNS Server IP to authenticate the DNS
Server, DoH needs to somewhat know the IP address for a given DoH Server
domain name to actally reach out to it.

However, in DoH's RFC, there is a little paragraph that raised the idea
to me, that could fix the bootstrap problem of DoT outlined in section
6.1 of RFC8310.

When the DoT is providing a TLS server certificate with a IP SAN
attribute for it's IP address, the DoT client can authenticate the DNS
Server using the DNS server's IP address as the authentication data.
This way, no extra to-be-configured ADN is required since the IP address
must be specified anyway.

Do I miss something or why hasn't this being considered in RFC8310?

Regards

           - Alex