IETF Logo Mail Archive

Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

"Henderson, Karl" <khenderson@verisign.com> Tue, 20 August 2019 13:54 UTC

Return-Path: <khenderson@verisign.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E3120274 for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 06:54:36 -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=verisign.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 WDIQdEA-udmM for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 06:54:35 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 6CB1E120271 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 06:54:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1638; q=dns/txt; s=VRSN; t=1566309276; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=49/zMiszXwDq41GjZa1R2U5Nx55anIc84PR0RU3bSe0=; b=Pmn8scRWrKgCPf5cmyPD+JZ0op1VSJbHQbtAqRqZhm+s4QWjHYCYilab D107sU9MOojvX/qX8kANDe8ChbBxXsPNK8k0a9+G9K+Zx9x7mQy72A91n uY6lPU6T6+DAZQd2C2aX1c0Gh/IJ6ZQNBZOtQXwXE6evSMcrij5I7zyqP K0oufcTOYfIkBue7CqAz89l2IYqOaGfd1g4bLTd055X00eh4FL+EZBdJJ /5/z9v82qNpCSYDT1hZuRh3xqxR8lS600fPr/sj86PUJNlMFZtjPsArYd Gs0wENsK4V4yODglHKddOXTFNrVjvnc45r0dR9j3H5ImAkGOXrVNA/Cfp g==;
X-IronPort-AV: E=Sophos;i="5.64,408,1559520000"; d="scan'208";a="8992784"
IronPort-PHdr: 9a23:s/xuzhK2ovxrMS0WTtmcpTZWNBhigK39O0sv0rFitYgXK/v9rarrMEGX3/hxlliBBdydt6sezbOK6uu9AiQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTagf79+Ngi6oArMusUZgYZvJLs6xwfUrHdPZ+lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2465MvwtRneVgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVzmu87tnRRn1gyoBKjU38nzYitZogaxbvhyvugB/zYDXboGbNvVxcKLdcs8VS2VORctRSzdOAoagY4cTFecMP+BVpJT9qVsUqhu+ABGhCO3txDBWgH/5wLM10/46EQHB2gwsB88FvnHOo9XvMKceX/2+wa7LzTXDcfxW3yry55bSchA6pvGMW6l9cdTPxkk1FgPFlVSQqYPjPz+PyusNtG2b4vNmWOmyiGAnsxl8riWzyss2l4XEhIwYxkrZ+Sh5zos5P9K1RUpjbdK5DJdcrTyWOolqTs84Xm1ltyU3xqcbtZO4ZCQKxoooyh3DZ/GCdoWF4A7sWPqLLjp9mX5qZK6wihOy/Ee91OL8WMy53VJXoSVYjNbBsG0G2QbJ5cidUPR9+1+s2TOI1w/O9O5JOVs0la/HK545xb4wi4YTvVzDHiDonEX2i7ebe1g49Oaw9ujoYq3oqJCdOINolA3yKLouldC4AeQiKggCRXKU9vmm2L395035W7NKgucqnanetZDWPcUbpqinDA9Jyosv9gqzAy273Nkak3QLNk9JdRKJgoTzNFzDJOj0DfKljFStlDdryerGPrrkApjVLXjDkKnufbBg5EFC0goz1tdf55RPB7EfPv3zQE7xtMfZDh82NQy42froCNJ41o8GQ2KAHreZML/OsV+P/u8vOPWMa5ENuDb9Nfcl4eTijXEjll8HZ6mmw58XaHSjE/t6OEWVe2bsjcscHmsQvwoxUvTgiEeeXj5Le3ayQ6U86ykmB4KgFofPX5itgKaA3CelBJJZemBHB0uNEXj2a4WEVe0AaCWIIs9uijYET6SuS5c91RGysw/306FoIfTR+iICrpLsyMN45+LUlRE1+jx0C9qS33uRQGFzm2MCXyU207xnoUxh1leD1rB1g/xdFdNP4PNESRk1NZjCz+BgFt/yRh/Bcs2UR1alEZ2aBmR7Vc48298DZQBzEs+4gxTH9yGxRaMem/qKCdZ8prnA0mDxKsA7xX/czqQli3EtWY1TPmHgh6Mps0CZC4jS1l2DlrijfrU03SPR+iGE12XE9BVUVhU1Sb/EQ3kUd2PXoMj3oETYQOnqQf4tPw5I0sWqJaxNZdnky15BQb2rbN7TZmuqkE+/AhGHwr7KZ43vLSFVliXYA08sngYNu3qaKE4yBW3p92LbBztGGFTxJU/w7K9yqyXoYFUzylTAT0Bn27ev4RkTwbS/QukXlPpQuycsrTl5Bk262frIBsCBvAtueuNXZtZrswQP7n7QqwEoZs/oFKtlnFNLKwk=
X-IPAS-Result: A2EsBgAy+1td/zGZrQpmHQEBBQEHBQGBZ4FpgkoKhBWQeyWDapckCQEBAQEBAQEBAQcBLwEBhD8CF4JhOBMCBQEBAQQBAQEBAQYDAQEBAoYcgjoignABBR0GEVUCAQgYAgImAgICMBUQAgQBEoMirVeBMopBgQwojAGBQT6BEScME4JMPoQuLYJ0MoImBI8TnEIDBgKCHZRUmEaNW5gOAgQCBAUCFYFngXpwegGCQYJ6jg1yjieBIQEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 20 Aug 2019 09:54:30 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Tue, 20 Aug 2019 09:54:30 -0400
From: "Henderson, Karl" <khenderson@verisign.com>
To: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "bemasc@google.com" <bemasc@google.com>, "hmco@env.dtu.dk" <hmco@env.dtu.dk>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations
Thread-Index: AQHVV1ybxB+rxlRoREmnLJlN+7zGwqcET7MA//+/O4A=
Date: Tue, 20 Aug 2019 13:54:30 +0000
Message-ID: <B91A1CC7-9BF8-4406-A402-BA7E101F8E7F@verisign.com>
References: <6CD20313-147F-40A9-91D2-16F2E19A4B48@verisign.com> <19d1358f-52cf-6f67-f53f-7084c6c8c115@cs.tcd.ie>
In-Reply-To: <19d1358f-52cf-6f67-f53f-7084c6c8c115@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <95DC8164AE36BD4C856DFAB4F2B92B17@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/zcEcVdcOqCoeoTcWnHaITQ3ZYPE>
Subject: Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 13:54:37 -0000

Hi Stephen,

I agree we need a service discovery mechanism as specified in the considerations document. However, isn't this the same problem that both stub-to-resolver DoT and stub-to-resolver DoH face? If so, why do we accept these as protocols without this mechanism specified but we don't for ADoT?

Regards,
Karl

On 8/20/19, 9:46 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

    
    Hiya,
    
    I'm not who you asked but...
    
    On 20/08/2019 14:38, Henderson, Karl wrote:
    > To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply
    > DoT with a prepended A to disambiguate the path taken.
    Doesn't the need to figure out if an authoritative
    server does/doesn't do DoT before sending a query
    require something new that isn't in DoT and that
    must be part of ADoT?
    
    If so, ISTM that there is a new protocol spec of
    some sort needed even if 90% of the meat of that
    is the reference to DoT. (I guess maybe if the
    answer for discovery was "does it listen on 853"
    you could argue that's not new but I didn't think
    the WG had figured that out yet.)
    
    Cheers,
    S.

v2.23.0 | Report a Bug | By Email