Re: [DNSOP] DNSSEC as a Best Current Practice

Joe Abley <jabley@hopcount.ca> Tue, 22 March 2022 10:28 UTC

Return-Path: <jabley@hopcount.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 9B1883A0E60 for <dnsop@ietfa.amsl.com>; Tue, 22 Mar 2022 03:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, 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=hopcount.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 3tnz9VKo6kDG for <dnsop@ietfa.amsl.com>; Tue, 22 Mar 2022 03:28:40 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 A1EA63A0E5A for <dnsop@ietf.org>; Tue, 22 Mar 2022 03:28:40 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id r13so35198660ejd.5 for <dnsop@ietf.org>; Tue, 22 Mar 2022 03:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=TjVqkMqo3UJFOtMMEtuMDvbHgsS3D4FMhZgpm7CbnlA=; b=m0DZlamND5lsXHbGdZMyjOq2k+evK5xT6XBKcjG6v/KXw+U96MClm5p+ioAZL8NFRT LrdS4oZIR1GZOwKUHLZ1gXH0l9WxYOEDpolrLRx/n4eVxkf2A8Ulk46FhXajfKR3Y6oH V6/cYW4lGp4fGcr6y8RATVtFbcAiCSnZZDNuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=TjVqkMqo3UJFOtMMEtuMDvbHgsS3D4FMhZgpm7CbnlA=; b=XHdPKOIAYDmbvUhQYvnNZLhfIc36N2VI9DVDcgaX7p5QyH2EwVltdLIFfKhLxwDp0A pi5ePhxtH9R5WW76qfyKQnYXS/CFY72YHz01FXJNADucsicdTZh0fXP1t/SPv4mGoNG1 qJCnMEK+ozk27Z0dtbGWHQRz81nIrMMz1FD2rztU6mCBsSZ3Jq3nL/+A5kjNevKTn3pF CNFI2eXdSk3BGBnTYOzGaNPo9qzigmB4e1FmuCwMrjGcO9BkwBt8eGFm/pKY9FXWYKLJ G5USjhlqpADkC4IKycbEVsncRvAe7oLrugINzf4Mi7IzsGbrJ7jXUXHcQ67TYK5sue2I yq9A==
X-Gm-Message-State: AOAM530+n8QuQban+YliHWyIWg4UrKz86X4c4eDuM2/1QcP/ZfFn/IUc Eh4d8YGw2+hzqSnKqgTaw9cosjqSi6JBTw==
X-Google-Smtp-Source: ABdhPJyAxFHsxTuhVocQ0bhBLDacZFBMKCnS1zVvLNlfknsicxWExSyMYNLjW08xjIHzxCSB46QdEQ==
X-Received: by 2002:a17:906:1411:b0:6da:f354:fb83 with SMTP id p17-20020a170906141100b006daf354fb83mr24672548ejc.539.1647944918593; Tue, 22 Mar 2022 03:28:38 -0700 (PDT)
Received: from smtpclient.apple (89-200-43-7.mobile.kpn.net. [89.200.43.7]) by smtp.gmail.com with ESMTPSA id w2-20020a50d982000000b00410dc0889b9sm9454002edj.63.2022.03.22.03.28.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 03:28:37 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Tue, 22 Mar 2022 11:28:36 +0100
Message-Id: <7B3A5D3D-2E84-45A7-BE5F-3BAC3650E95C@hopcount.ca>
References: <163bfd78-c21d-084c-9f6d-9d29b80bcbd1@necom830.hpcl.titech.ac.jp>
Cc: Bjørn Mork <bjorn@mork.no>, "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <163bfd78-c21d-084c-9f6d-9d29b80bcbd1@necom830.hpcl.titech.ac.jp>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: iPhone Mail (19E241)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v6SvjKf_MXJKhIsbrlHZ6CYSZ3s>
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: Tue, 22 Mar 2022 10:28:46 -0000

On Mar 22, 2022, at 10:06, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

> Bjorn Mork wrote:
> 
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which describes
>> this "secure enough" alternative to DNSSEC?
> 
> As I wrote "rely on DNS cookie or something like that",
> an example is in rfc7873.

Could I perhaps summarise what you're saying as follows?

1. The cost of DNSSEC signing is high, e.g. due to increased complexity, brittleness of the DNS, perhaps as shown by relatively low demonstrated system-wide deployment;

2. The threats that DNSSEC protects against are not high-probability threats, especially following the adoption of various resolver-hardening techniques adopted following the late Dan Kaminsky's various observations;

3. The threats that DNSSEC protects against are not high-impact either since they affect one layer amongst many for most applications;

4. Protocols and applications that depend on cryptographic assurances in the DNS (DNS as PKI) are few and far between, e.g. low uptake of DANE for protocols other than SMTP;

5. The cryptographic assurances in DNSSEC in any case are not absolute, e.g. since they depend on accurate trust anchor maintenance that is subject to interference by nation states, mobile device management, manipulation through system compromise;

6. Better to avoid the cost of DNSSEC deployment given its low value and focus instead on other approaches like cache-hardening or improving transactional integrity using cookies. 

Does that come close to what you're getting at?


Joe