Re: [DNSOP] Privacy and DNSSEC

Paul Vixie <paul@redbarn.org> Thu, 30 April 2020 07:15 UTC

Return-Path: <paul@redbarn.org>
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 98AAF3A0A09 for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 00:15:50 -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 L6lpGL2EQamm for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 00:15:47 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7053A0A0A for <dnsop@ietf.org>; Thu, 30 Apr 2020 00:15:47 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 44E98B074A for <dnsop@ietf.org>; Thu, 30 Apr 2020 07:15:47 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Date: Thu, 30 Apr 2020 07:15:45 +0000
Message-ID: <6331597.vK9gVth8U1@linux-9daj>
Organization: none
In-Reply-To: <CAHPuVdWoWUmYCfx3mv1J9iiDmMzV=YCytsn8xwSf_u_nOUmj4g@mail.gmail.com>
References: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com> <21757930.7KVZAQyxnt@linux-9daj> <CAHPuVdWoWUmYCfx3mv1J9iiDmMzV=YCytsn8xwSf_u_nOUmj4g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vg7fqMHgSlhmlnN-L1ELchVkubM>
Subject: Re: [DNSOP] Privacy and DNSSEC
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: Thu, 30 Apr 2020 07:15:51 -0000

On Wednesday, 29 April 2020 13:44:12 UTC Shumon Huque wrote:
> On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie <paul@redbarn.org> wrote:
> > ...
> 
> This is by no means a problem unique to DNSSEC. Many new protocol features
> have and continue to face the middlebox challenge: SCTP, TCP fast open,
> multi-
> path TCP, QUIC, TLS 1.3 etc. Some have developed workarounds with varying
> degrees of success, some like SCTP have more less died. The web has the
> advantage (in my opinion) that a small number of browsers are able to impose
> changes on the middlebox ecosystem in a way that the DNS will never be able
> to.

so, there were two modes. first, the web was created. it worked everywhere and 
required no upgrades to the OS or any other protocol or any gateways or 
firewalls. later (today), the web is dominant and if it makes a change that 
doesn't work everywhere, the pain will be felt everywhere, and every operating 
system and gateway and firewall will conform or die.

DNSSEC has never been in either mode. depending on DNSSEC for a product or 
service remains commercial suicide and always will. thus noone invests in such 
products or services, and anyone thinking about the X.509 CA problem ignores 
DANE and focuses on cert-pinning or similar.

the pre-DS clear path requirement was really "allow unknown RRtypes". the 
post-DS clear path requirement was really "understand DS". that was a change 
we made, that stopped all progress beyond "let's opportunistically protect the 
RDNS cache, and geeky stuff like SSHFP, and DANE for SMTP".

> As I mentioned in a previous note, DNS over HTTPS (however one might feel
> about current deployment models and such), can probably provide the clean
> path that end user applications of DANE need.

i heard you say that, and i disagree, but it's off-topic, so, another time.

-- 
Paul