Re: [DNSOP] DNSSEC as a Best Current Practice

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 07 April 2022 19:36 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 553293A12FF for <dnsop@ietfa.amsl.com>; Thu, 7 Apr 2022 12:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (2048-bit key) header.d=gmail.com
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 H8PXUOb-ZrLJ for <dnsop@ietfa.amsl.com>; Thu, 7 Apr 2022 12:36:54 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E55E3A15B4 for <dnsop@ietf.org>; Thu, 7 Apr 2022 12:36:54 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id l7so7576411ejn.2 for <dnsop@ietf.org>; Thu, 07 Apr 2022 12:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yFEn0mGI4waGZ+hf3ezJryfXiZlZ5FIavDw3B2Vq0mI=; b=Usq/JYeI5t9O1p2Pq8tpX5O4c6b7qpKxeSeW46h1ybc4eZui7D3JtJEG50ucBnAmeA NI0/M4WeX2N7UlBL88arYrenDV5DSwnCV78HtIjz5QLoyZTddx0aGTl0SGD+gJESYRt8 +qQIjzDc041FWpcOeVX3OoLktR+0T4P+M0bftPzmkYMhMPMYc3TIzPz0KfkICh6+uTh2 HglX6zFiGK+jOmQlP3MdzRcpJuOfuSQaAiyDHR7REJd/kzOQ9MQ2oaIuATnKNaBGECCa euUYYrODyFiT6ABGSqavCDcEKIqUhxNkqP1jhWDdIayvRWUyfXrNsH7TF78YRD+DxVls iDDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yFEn0mGI4waGZ+hf3ezJryfXiZlZ5FIavDw3B2Vq0mI=; b=ebcMde+lzyCdcgMR5yMDN+Z2g8SspzR8AgIGScS6QnLB35ZX8H42VEn413oDtWNUuS JQY5EwmxygHBjh6A/IAMAZfj9+fZs1BbH6wNBnDkAy4liKgMFaW+oah3+jGAxrHyhsla ort3M+u8Aj/mdnLjrTs+ohcW5LBjKe1iA87UvXfqB+2dNM0+MzqZ047TGDunSYlhQ63P g2ohYE7XB7X4igHtjigLiu8ka1zveLmmDTSxSUgAOWtlGb298MvkJwbNZRO9V6AGvcKP R8F23gDe7HDUz4BjI6BjMtOnIHjq7f7cb1aEma4Dms/C1aMBR2jKLwwvDjXNvuFaL2yA Zi5A==
X-Gm-Message-State: AOAM530xCyyjWiAABEgk5hiciNJ1mhzvNb872ipkSj+yhGp2GLvJE5+o CjzNkYjUUObamiVms0AT83mlAs1deDQAaZC4/qADzxJCG7Y=
X-Google-Smtp-Source: ABdhPJxFQHK4l+2f5idJDduFArmjcJ/LZakbUE+Z4onzd72lm/xFEs2cjXXutip/igKtrmSJdxHAQuAi/VzEeuX/vTo=
X-Received: by 2002:a17:906:7742:b0:6e8:3f85:4da1 with SMTP id o2-20020a170906774200b006e83f854da1mr3267995ejn.495.1649360212444; Thu, 07 Apr 2022 12:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <A9F689C9-4ABF-4947-AA6B-56E2F0C17D13@nohats.ca> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp>
In-Reply-To: <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 07 Apr 2022 12:36:40 -0700
Message-ID: <CAH1iCiqkAPHq1QBKdkbh86j8UhimjEMG9DU15O9Tkch4BedBjg@mail.gmail.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000091c85205dc159902"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OsDNxbFAW4oFWOEpTBO6J5qPoX0>
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: Thu, 07 Apr 2022 19:37:00 -0000

On Thu, Apr 7, 2022 at 5:45 AM Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> As I wrote:
>
> >> Such an individual would have to get access, create the records, give
> >> them to others, who then have to on-path attack you. At the TLD level
> >> and higher, this involves HSMs and physical access restrictions using
> >> a “four eyes minimum” approach.
>
> > Not surprisingly, diginotar was equally strongly secure.
>
> Are there anyone who still think DNSSEC were cryptographically secure
> or had protected TLDs more securely than diginotar?
>

I'm not sure why "thinks" enters into the conversation.

Nobody is entitled to their own facts, only their own opinions.

The facts are what matters here:

   - Each TLD has its own specific infrastructure, practices, etc.
      - Not all TLDs are equivalent for purposes of comparison of relative
      security (to each other or when compared to corresponding CA
infrastructure
      and practices)
   - Each TLD is a monopoly for the purposes of DNSSEC. The TLD operator
   has exclusive control over the delegations (including DNSSEC components) to
   registrants.
   - Registrants choose the TLD to use when they register a domain
   - Modulo the restrictions applicable to specific TLDs, the available
   choices of TLD are substantial
   - Each CA (including diginotar) is not a monopoly. Any CA can issue a
   certificate for any domain name.
   - Each CA has its own specific infrastructure, practices, etc.
      - Not all CAs are equivalent for purposes of comparison of relative
      security (to each other or when compared to corresponding TLD
      infrastructure and practices)

Taking these facts into consideration, the following assertions are clear
consequences:

   - Some CAs MAY have stronger infrastructure and practices than some TLDs
   - Some TLDs MAY have stronger infrastructure and practices than some CAs
   - It MAY be the case that some TLDs have infrastructure and practices
   that are not exceeded by those of any CA
      - Rephrased: some TLDs >= all CAs (which includes the boundary
      condition of "some TLDS == some CAs" without explicitly claiming that set
      is non-empty)
   - An attacker who wishes to compromise a domain via a WebPKI
   certificate, can choose which CA to use for this purpose
   - An attacker who wishes to compromise a domain via DNSSEC delegation,
   cannot choose which TLD to use for this purpose

Taken together, this means that as long as there exists any CA which is
weaker than some TLD, that automatically means that as a global system,
DNSSEC is more cryptographically secure than WebPKI.
And, given the facts regarding diginotar, this means that as a system,
DNSSEC is more cryptographically secure than diginotar.

QED

Registrants get to choose the TLD. Once that decision has been made, the
attacker has no alternatives to that TLD in terms of what would need to be
compromised to affect that specific domain.
The same is not true of CAs. Any CA being compromised places every domain
(regardless of TLD) in jeopardy, if the only protections on certificates
are those currently employed (e.g. CT, CRLs, OCSP).
If/when DANE (TLSA records) are used to improve certificate validation, the
choice of CA for the attacker to compromise is removed from the equation.

Brian