Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Paul Vixie <paul@redbarn.org> Mon, 15 July 2019 01:59 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 B243C120163 for <dnsop@ietfa.amsl.com>; Sun, 14 Jul 2019 18:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 RmM2i93yVRRM for <dnsop@ietfa.amsl.com>; Sun, 14 Jul 2019 18:59:29 -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 E6E84120143 for <dnsop@ietf.org>; Sun, 14 Jul 2019 18:59:28 -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 C39B8892E8; Mon, 15 Jul 2019 01:59:28 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Rob Sayre <sayrer@gmail.com>
Cc: dnsop@ietf.org
Date: Mon, 15 Jul 2019 01:59:28 +0000
Message-ID: <3220557.rvQTihJl8x@linux-9daj>
Organization: none
In-Reply-To: <CAChr6SyapDz8ZKNU8nOuncPMWajBuE+eF3WMFP9GWAs+B-uP9g@mail.gmail.com>
References: <CAChr6SyVmgMpD6Cd=m2Z03nts-Bv9ZVgJkG8oaj_jzwYMUZuCg@mail.gmail.com> <4966582.gC1Lsr5W4Z@linux-9daj> <CAChr6SyapDz8ZKNU8nOuncPMWajBuE+eF3WMFP9GWAs+B-uP9g@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/r5eU4XnWWCPSrn18cJF81hkUy8g>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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: Mon, 15 Jul 2019 01:59:31 -0000

On Monday, 15 July 2019 01:41:10 UTC Rob Sayre wrote:
> Thank you for the elegant response. BCP 61 describes this issue well, too.
> 
> https://tools.ietf.org/html/bcp61
> 
> DNS seems like it still operates in the clear, and that doesn't seem good.

first we signed transactions with asymmetric keys -- SIG(0).

then we signed them with symmetric keys -- TSIG.

then we signed data with assymetric keys -- DNSSEC.

then we encrypted transactions with assymetric keys -- DoT.

the the web community caught wind of it and threw a molatov cocktail into our 
movie theater -- DoH.

changing DNS isn't quick or easy or cheap -- it's the trifecta of "fast, good, 
or cheap, choose two" and you have to say "i choose none of the above."

and DNS is nowhere near as simple as the web community wants to believe.

we could use a lot more help pushing DNSSEC and DoT, for end to end 
authenticity and hop by hop secrecy+authenticity. we've done the parts of 
these that weren't quick and the parts that weren't easy and the parts that 
weren't cheap as well as the parts that weren't and can't be good. what we 
need now is a unified deployment effort on these technologies. help?

-- 
Paul