Re: [DNSOP] DNSSEC as a Best Current Practice

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 23 March 2022 12:56 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 1A6C03A10D4 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2022 05:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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 pYQ69eEzRCEF for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2022 05:56:46 -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 ABCDD3A10F2 for <dnsop@ietf.org>; Wed, 23 Mar 2022 05:56:45 -0700 (PDT)
Received: (qmail 85929 invoked from network); 23 Mar 2022 12:52:54 -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; 23 Mar 2022 12:52:54 -0000
Message-ID: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp>
Date: Wed, 23 Mar 2022 21:56:42 +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: Ted Lemon <mellon@fugue.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <163bfd78-c21d-084c-9f6d-9d29b80bcbd1@necom830.hpcl.titech.ac.jp> <7B3A5D3D-2E84-45A7-BE5F-3BAC3650E95C@hopcount.ca> <e722a37a-1476-d90b-b4df-e9d4604bea59@necom830.hpcl.titech.ac.jp> <e8566381-d8e8-b99f-67c3-2e89dc9cb85@nohats.ca> <affe488c-d2c4-05a0-69b4-12c2aa97dbfa@necom830.hpcl.titech.ac.jp> <CAH1iCip7buO_WAteXn24jDics=MOGHFMcRxvbO1O9Z-HyErdAA@mail.gmail.com> <CAPt1N1kKVwezh+vK7djT1YdYLFHmHSSPRYbxRxmPYMh4ck_LGw@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <CAPt1N1kKVwezh+vK7djT1YdYLFHmHSSPRYbxRxmPYMh4ck_LGw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HWag5xdX6_XYadO7FGfTZZSrlCM>
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: Wed, 23 Mar 2022 12:56:48 -0000

Ted Lemon wrote:

> Brian, what you said about the crypto is right but there are definitely
> opportunities to compromise trust at the tlds. I don't think it's wise to
> ignore this type of attack. However, in order to make such an attack, you
> have to do things which can be noticed (e.g. signing a zone delegation with
> a forged key).

If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address
of a forged nameserver using forged public/secret keys)
is signed by a valid key, it will not be noticed easily.

> So the threat model for a viable  DNSSEC attack is quite a bit different
> than for a recursive resolver attack, and is not something that could be
> easily effected by a small entity.

Merely because message ID is short, which can be improved,
which is a lot easier than deploying so costly DNSSEC.

 > And unlike
 > a resolver attack, it is possible to detect a DNSSEC attack by
 > comparing known keys to detect a compromise.

If a resolver has some knowledge on contents of an attacked zone, such
as IP addresses of some servers or some DNSSEC keys, it can detect
a DNS (both resolver and DNSSEC) attack by comparing, unless
an attacker knows IP addresses of detecting resolvers and
return unforged answers to them. So?

Unlike that, birthday attacks on resolvers are trivially detectable
by the resolvers.

						Masataka Ohta