Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 30 October 2020 21:38 UTC

Return-Path: <shollenbeck@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 833DA3A1264 for <dns-privacy@ietfa.amsl.com>; Fri, 30 Oct 2020 14:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 FF2qAJIHYvYH for <dns-privacy@ietfa.amsl.com>; Fri, 30 Oct 2020 14:38:30 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 14B3B3A1262 for <dprive@ietf.org>; Fri, 30 Oct 2020 14:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2268; q=dns/txt; s=VRSN; t=1604093910; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=m1FEK40+19cYWqnm8tcD5QllZRXMABnhzp5o3Of+Jcw=; b=Gi8scOiy0sJLzg9PmzTQWlduDvBbRawjFpnbMQHfpMKWwbf1iXmI7YiQ Sa/N0v33kEY9nwvCRjtd8dt9VMTdxn39Yhk3U9LaQQU13tvLm/3qdnpYF +Vy3xNBvCmvIOTlURttzUnkTNJ0IfgdxHGYZSnxsPUUmXAgFILXWTLL8d PNR12g8tCAKfHITC8Y36fj5PT2FQwK6qCicGVatCtWpO5261JPqfQlh62 913wlxvQLmtMhLIzt2jWYyMHy0q1lB5vFBYrqksE326eO9F12lP3QP7k1 GcxtJIajEbsDRu7p6r1LweScN3s49VSyrZLqMoAuZtUbX3L81W6CYXYta Q==;
IronPort-SDR: VY1upUkHskt1bybFD8JrwdkEojL5tEIjKwVoeDxbPB6olrwgbCgOlWlltclbUfAXjZjYBPHgVv U8k6yEqR8vN0Do+Xb06Oez+TPJlKngvGpPpiSSO3Vp9f6SNGP4gpxcM5EPjkFtKy5yVQwR2FWr G2XZHA2vxE+y7IT6yGBkW4M8LAA2T101Y2LiAlbZPAWe9ZCl9fV0d+FM1TNfAmfbUKm/BnFEqK n0R0Tf6jdrfdfgbvQH9IuDAiaRH82E2YwtEUfkgDa+ej2T4W/ManZprwaR4R/8jZW8dJ8MNf3K 81g=
X-IronPort-AV: E=Sophos;i="5.77,434,1596513600"; d="scan'208";a="3450028"
IronPort-PHdr: 9a23:Op1V+BH/oFks+iF5k1DnBp1GYnF86YWxBRYc798ds5kLTJ76p8m7bnLW6fgltlLVR4KTs6sC17OJ9fG9EjVcuN6oizMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLhi6twHcu8kZjYd/Jas91wbCr2dVdehR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG87+MPktR/YTQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD+/4apnVAPkhSEaPDM/7WrZiNF/jLhDrRyhuRJx3pLUbo+WOvpwfKzdfM8VS2VOUctKSyxBG4G8Y5cTA+YdI+pVqZT2qVsUrRu5AAmhHO3jxD1Phn/y2a01zeIhHhrY0wM8HNICqGnfosjpO6cVTeC10KfExijEYvNN2Tf974zIchQ/rvGKRr1/b9beyUo0GgPbkFqQs43lPyiU1uQCtWiX9fZvVeWqi2M+rQx6vzegyNs2hIbTmoIV1k7L9T9/wIstONC1SE52bMK6HZZSqiyXM4R7T94tTW10vCs21qAKtYK1cSYE1ZkqxBHSZ+Cbf4aI4hzvSOifLDV2in97fL+ymxC/+lWjxO3kTsS4zUpGojBYntTOuH0BzQHf58iJR/dn8Uqs2i6D2x3P5u1ePEw5l7bXJ4Q8zrM/lZcfq1nPEyzwlU7rlqGZbF8k9fKt6+n/Z7XmoYKTOJFshwHlN6QuhtS/AeMlMggSR2Sb+fqz1Lnk/UDhXbhEkuU4nrTZv57CKsoUp7K1DxJP3oY99xm/CC2m0MwCkXYdMV1JYgyHj5LyO1HIOvz3EfC/g1G0nDdqwfDJIKHhD43QInTfirvtYLRw5kBGxAYuzd1S6YhYB74CLf7rX0/+rt3YDhs3MwyuxObnDc1w1pgeWWKIBq+ZNL3dsVmT6e0xP+aMZ5QYuCjjJPg/5v7uln45mVAbfaWzwZQXb3W4Eux8I0qFeXrsnssBEWASswomVuPqlVmCXSRTZ3a1UaI86DQ7B5igDYrYR4CinKaO3CG9HpFMYWBGEF+MG2/yd4qYQ/cMdD6SIsh5nzMaVrihUZQs1QuytA/0zrprNPbb+iodtZj7zth6+/XTlQ0u9TxzF8mSznmNT3t1nmMWWTA7x6F/rlJhyleNy6R4hOZYFdMAr89OB00iPIPYiex9Bd73UwTpf9yATlDgRc+pS3llVtssx5kOZEhzHtykphHI1iysRbgPmOrPTNY58bj0xWT/IoB2zHOMnP0sjEMOWNdBMCutgasppCbJAIuc2WWek6Knc64R1y2JvFyIynaS9gkMSw53VaHIW3oSbUj+s9nj51jDQLnoArMiZFgSgfWeI7dHP4W6xW5NQ+3ubYzT
X-IPAS-Result: A2EmEgB1hpxf/zCZrQpiHAEBAQEBAQcBARIBAQQEAQFAgU8Cgh56gTYKlUmaLYF7CwEBAQEBAQEBAQgBLwQBAYRKAoIJJjoEDQIDAQELAQEBBQEBAQEBBgMBAQEChiEBBzGCNyKDdgEBAQEDDiwrFAwEAgEIEQQBAQEeEDIdCAIEAQ0FCIMfsmt0gTSFV4UZgTiNVYFCPoERgxI+hCaGDgS4HQMHgmyafCuhZpNHoD8CBAIEBQIVgW4LgW1wgzlQFwINgzWJb49EdDgCBgoBAQMJjAQtgQaBEQEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 30 Oct 2020 17:38:28 -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.2106.002; Fri, 30 Oct 2020 17:38:28 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "paul.hoffman@icann.org" <paul.hoffman@icann.org>, "ekr@rtfm.com" <ekr@rtfm.com>
CC: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: [dns-privacy] [Ext] Revised opportunistic encryption draft
Thread-Index: AQHWrv3CT++cQ/TPAkKNFcowr4LO9qmwqxcg
Date: Fri, 30 Oct 2020 21:38:28 +0000
Message-ID: <98ee1879e409496d8c3f9f40bcc80b8f@verisign.com>
References: <C0CBEBC5-D28A-46C0-AE50-078710015466@icann.org> <alpine.LRH.2.23.451.2010301202350.2587497@bofh.nohats.ca> <2444B21B-9465-4A5B-97CC-AF809309300A@icann.org> <CABcZeBPZFY9aQ5Nb0q_4uTMFRbY3-S2rus4vaeLaUmvU+h_ftg@mail.gmail.com> <2D07CBD0-30CE-418E-AD05-02E0A5EDB79F@icann.org>
In-Reply-To: <2D07CBD0-30CE-418E-AD05-02E0A5EDB79F@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/84_QFZysNeL0mE3dBtcmlt1qytU>
Subject: Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
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: Fri, 30 Oct 2020 21:38:32 -0000

> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Paul
> Hoffman
> Sent: Friday, October 30, 2020 4:46 PM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: dprive@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Revised opportunistic encryption
> draft
>
> On Oct 30, 2020, at 12:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters <paul@nohats.ca> wrote:
> >> > I still believe the cost of authenticating a DNS(SEC) server is so
> >> > low these days (with ACME available at no cost and with full
> >> > automation) that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost that is
> being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to authentication
> mistakes made by the authoritative servers (not renewing certificates, errors
> in TLSA records, upstream validation problems that cause TLSA records not to
> validate, ...) or resolvers (dropping trust anchors that are in use, bad
> validation logic for TLSA, ...).
> >>
> > How is this different from the transition of the Web to HTTPS?
>
> The DNS data is already authenticated if they are using DNSSEC. Also,
> because the DNS is hierarchical, even a short-lived authentication failure at a
> particular server will take out the ability to get data for all zones beneath that
> one; this is not an issue in the web.
>
> > Sure, there can be misconfigurations of various kinds, but good operational
> practices can minimize these, and in return you get strong security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the
> DNS.

This is an important point. Privacy can't increase the risk of a loss of availability, especially as we move closer to the DNS root.

Scott