Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers

Paul Hoffman <paul.hoffman@icann.org> Sat, 12 September 2020 00:13 UTC

Return-Path: <paul.hoffman@icann.org>
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 83C8A3A0770 for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 17:13:09 -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 uL8evvbwyhsf for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 17:13:08 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 04E153A0044 for <dprive@ietf.org>; Fri, 11 Sep 2020 17:13:08 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08C0D77b008103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Sep 2020 00:13:07 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Fri, 11 Sep 2020 17:13:06 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0659.006; Fri, 11 Sep 2020 17:13:06 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Paul Wouters <paul@nohats.ca>
CC: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Opportunistic encryption between recursive and authoritative servers
Thread-Index: AQHWiJl84yw/3jSNV02BKzH1iWO0og==
Date: Sat, 12 Sep 2020 00:13:06 +0000
Message-ID: <5AB5385A-FE70-4FB0-810A-1EF0762094E2@icann.org>
References: <BBA7E731-34C9-47C8-B584-7781DD7F4A59@icann.org> <alpine.LRH.2.23.451.2009111952110.1078938@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.23.451.2009111952110.1078938@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_477E2533-0191-40B0-AAB4-60ECC22DBE7C"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-11_12:2020-09-10, 2020-09-11 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/i-0HH_HSiP0s_I5O-DXDtXDkc4I>
Subject: Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers
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: Sat, 12 Sep 2020 00:13:10 -0000

On Sep 11, 2020, at 5:03 PM, Paul Wouters <paul@nohats.ca> wrote:
> 
> And as I've told you before, your use case of "opportunistic encryption"
> makes no sense here.

And many people disagreed with you.

> The DNS allows for publication of public keys without
> any further infrastructure. You need your TLS certificate for encryption
> anyway. Why not just stuff that public key into DNS via a TLSA record?

Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.

Secondarily because "just stuff" leads to errors that will lead to resolvers failing to get answers.

> This is not rocket science. We already do TLSA for email at large scale
> now.

You somehow missed the word "opportunistic" in that sentence.

> Opportunistic encryption to authoritative servers is just too silly.

Many people disagree.

> I am strongly opposed to doing this work.

You continue to say that without writing up your use case for review in this WG (or anywhere, as far as I can tell). The best way to support your use case it to write it down, not just snipe at those who have written theirs down.

--Paul Hoffman