Re: [DNSOP] DNSSEC as a Best Current Practice

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 21 March 2022 12:28 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 464E23A19B0 for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 05:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 a3wOgzVc8Mnx for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2022 05:28:32 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 8C27F3A19AB for <DNSOP@ietf.org>; Mon, 21 Mar 2022 05:28:31 -0700 (PDT)
Received: (qmail 47715 invoked from network); 21 Mar 2022 12:24:43 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Mar 2022 12:24:43 -0000
Message-ID: <6d46abd6-60ca-d896-6408-fe83a83895cf@necom830.hpcl.titech.ac.jp>
Date: Mon, 21 Mar 2022 21:28:28 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: DNSOP@ietf.org
References: <7aaed092-8877-ec15-9b7b-5d488e383d04@necom830.hpcl.titech.ac.jp> <7C43871E-60AF-485D-8AB3-65E72539F831@nohats.ca> <59fdc791-4482-141b-03b4-bc27e8824f31@necom830.hpcl.titech.ac.jp> <1cd37a4-2f80-5a8c-f377-d224a363d76@nohats.ca>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <1cd37a4-2f80-5a8c-f377-d224a363d76@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tbvHYmLDNVpXo7BwsaL4RZ6g9AA>
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 12:28:36 -0000

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?

The statement is not more demanding for resolvers to be configured
with correct certificates.

> This would not help for on-path attackers (without DoT, DoH)

See below.

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

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

>> IETF can do nothing if some government legally force
>> people to install some government provided certificates
>> to some PKI, including DNSSEC, which is as easy as
>> MitM attacks on ISP chain may be by government order.
> 
> With DNSSEC, a government in country X cannot spoof data of
> country Y, they can only block it.

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

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

						Masataka Ohta