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

Paul Wouters <paul@nohats.ca> Sat, 12 September 2020 01:00 UTC

Return-Path: <paul@nohats.ca>
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 11B4C3A097D for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 18:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 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, NO_DNS_FOR_FROM=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.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 k4aoPREdkaDC for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 18:00:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 360133A0977 for <dprive@ietf.org>; Fri, 11 Sep 2020 18:00:22 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BpDnJ4BnVzF3y; Sat, 12 Sep 2020 03:00:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599872420; bh=6uEZLBEQ6GXMXIMmMd9OVhV3ChR+NNsexjVWXQ6Z5MY=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=UU8DTK6CKKiNLibfIOeMnxj30qV33bxYXs1vXICfyz0vEfDu28Zd+i6EaPdsj12Jp IOa7aVPvxDSeFhuagQ0DPXGZX3KEAwt7vDaqziPoKJhbB7qg6D3jAJMnf/QwsgGHbe W9w1bI9La+sF+2NkhJGCNvPuy2W72Hm8rJwLdPRA=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id piXKMqgfsatf; Sat, 12 Sep 2020 03:00:18 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 12 Sep 2020 03:00:18 +0200 (CEST)
Received: from [193.110.157.210] (unknown [193.110.157.210]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 014836029BA6; Fri, 11 Sep 2020 21:00:16 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Fri, 11 Sep 2020 21:00:14 -0400
Message-Id: <8C8C42D7-EC2F-4374-A508-2BE3824B768D@nohats.ca>
References: <5AB5385A-FE70-4FB0-810A-1EF0762094E2@icann.org>
Cc: "dprive@ietf.org" <dprive@ietf.org>
In-Reply-To: <5AB5385A-FE70-4FB0-810A-1EF0762094E2@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: iPhone Mail (17H35)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/hgTvl3AOLXCNv7-Aq5KZHnOoprU>
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 01:00:24 -0000

On Sep 11, 2020, at 20:13, Paul Hoffman <paul.hoffman@icann.org> wrote:

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


Which of large resolver operators is not validating ? Which of the stock opensource resolvers is not validating with a default configuration ? 

Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them.

I think your argument does not hold.

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

That’s not different from web servers. It’s 2020, if you still require an unencrypted or in authenticated protocol, you are doing it wrong. Surely, we should not be designing for it.

The only reason to do opportunistic encryption is when authentication or identity management is hard. This is simply not true for authoritative DNS servers.


> 
>> This is not rocket science. We already do TLSA for email at large scale
>> now.
> 
> You somehow missed the word "opportunistic" in that sentence.

SMTP was largely opportunistic due to fear and complexity of getting certificates working. Since ACME that is no longer the case and it is as easy to setup postfix with acme as it is using selfsigned certs. At this point I would also argue against opportunistic for SMTP, although the case for SMTP is stronger due to mail relays within networks that cannot gets a public cert because they are not public.

> 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.

How do I write up a use case of “don’t overengineer for complex crypto that might accidentally skip authentication of your encryption and cause security vulnerabilities to support people who can only create selfsigned certificates for their DNS server” ?

Paul