Re: [DNSOP] DNSSEC as a Best Current Practice

Paul Wouters <paul@nohats.ca> Mon, 21 March 2022 13:59 UTC

Return-Path: <paul@nohats.ca>
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 A86AF3A094C for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 06:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 lgh3Efg3O4CE for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 06:59:40 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 254EE3A08FC for <DNSOP@ietf.org>; Mon, 21 Mar 2022 06:59:40 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4KMbpK5GBJz3VV; Mon, 21 Mar 2022 14:59:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1647871177; bh=CzU6J1wJ4BEgnPrB0azr/kiFBDLodsgTIEYEPTQaV+M=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=DqlT/P5Foa8Zt5J/Y3YillSm83QP6czkY1d9RUY9PHbuh9dqP5AVyFSK9Z7DUUcHa XQV9PsiodBNs3JmXXhisukK8j49VeJP2dp7QAl2r2ysh4BKPimPD2qU4R0its/D6KU FNT7pJtfnevdXYUj01KBUSsxeV7LkvNM3Cg0KZYw=
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 cch0Y6aJdw5E; Mon, 21 Mar 2022 14:59:36 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [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; Mon, 21 Mar 2022 14:59:36 +0100 (CET)
Received: from smtpclient.apple (dhcp-88f1.meeting.ietf.org [31.133.136.241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id AF1522CE382; Mon, 21 Mar 2022 09:59:35 -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: Mon, 21 Mar 2022 14:59:32 +0100
Message-Id: <6B319F45-B5B6-4CB7-8E74-EA3651296C0E@nohats.ca>
References: <6d46abd6-60ca-d896-6408-fe83a83895cf@necom830.hpcl.titech.ac.jp>
Cc: DNSOP@ietf.org
In-Reply-To: <6d46abd6-60ca-d896-6408-fe83a83895cf@necom830.hpcl.titech.ac.jp>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: iPhone Mail (19D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HhgFTeifPM7VxrSpM2-Mhc41JlM>
Subject: Re: [DNSOP] DNSSEC as a Best Current Practice
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, 21 Mar 2022 13:59:47 -0000

On Mar 21, 2022, at 13:28, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
> 
> Paul Wouters wrote:
> 
>>> If a resolver correctly knows an IP address of a nameserver of a
>>> parent zone
>> This statement seems a recursion of the original problem statement?]
> 
> What?

You claim DNS can be secured if we somehow securely know all the IPs of all nameservers of parent zones, for which the only source is DNS. How do you propose to fulfill your own stated requirement without DNSSEC ?


>> How would this be safe against the current BGP attacks we are seeing?
> 
> Are you saying connecting to an IP address secured by DNSSEC
> is safe even under BGP attacks?

Yes. Obviously the attacker can deny the actual real DNS content but sending their own made up DNS data is ignored due to data origin protection. 


> 
>>> As for MitM attacks, PKI, in general, is insecure against
>>> them as was demonstrated by diginotar. So, don't bother.
>> DNSSEC is more hierarchical than the "bag of CAs", so a failure
>> like this would be more contained. Regardless, I do not understand
>> how PKI failures relate to DNS?
> 
> Are you saying you don't understand DNSSEC is a form of PKI?

Please refrain from ad hominem attacks if you wish to continue to discuss.

A webpki root ca failure has no relationship to dnssec which has no root ca’s.

> Country X legally forcing people to install government provided
> root certificates can freely spoof PKI, including DNSSEC, data
> of country Y.

No they cannot. I can give you root access to a nameserver for nohats.ca and you still can’t create a “proof.nohats.ca” DNS record that google DNS would serve to people. Similarly if we imagine you can coerce country X to do anything you want, how you could get this DNS record published so that the world’s servers/clients will believe your answer to be true. 

>> Again, I think perhaps you should write this up in a draft, so
>> we can see how your proposal would cover everything that DNSSEC
>> covers.
> 
> Before diginotar, maybe. After that, I don't think it necessary
> any more.

If you only handwave your claims, the only possible IETF response is to not spend time on your claims. I have now given you two methods to substantiate your claims to further the discussion.

Paul