[DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06
Paul Wouters <paul@nohats.ca> Mon, 03 July 2023 06:06 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 0E8C8C14F721 for <dnsop@ietfa.amsl.com>; Sun, 2 Jul 2023 23:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh0q78AkghJw for <dnsop@ietfa.amsl.com>; Sun, 2 Jul 2023 23:06:19 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 111B6C14CF0D for <dnsop@ietf.org>; Sun, 2 Jul 2023 23:06:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Qvb5g2fBkz313 for <dnsop@ietf.org>; Mon, 3 Jul 2023 08:06:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1688364375; bh=oBto8KrN+/3ZRP9WlWDRsDNjqZOLwXgKS4tg1eUNtew=; h=Date:From:To:Subject; b=s5w+F4TuDcl0Q1Jdgkv0eE4VviAGfbsshYym9kmzeWLIEx7SSoSALn/64Ma0Q0dzZ u0Rznv9OWSJejEvgXBHsrlASJqZJyF2wKzTdsa5ksaVHZA3LSkqz/PCXoHE9A0Ox7s +ypoWHvugfleT/uWn4Y3fRR/e6i+0V4lBbxdEiu0=
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 QUx27tXqvowK for <dnsop@ietf.org>; Mon, 3 Jul 2023 08:06:14 +0200 (CEST)
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 for <dnsop@ietf.org>; Mon, 3 Jul 2023 08:06:14 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A1481019464; Fri, 30 Jun 2023 16:15:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8709D1019463 for <dnsop@ietf.org>; Fri, 30 Jun 2023 16:15:09 -0400 (EDT)
Date: Fri, 30 Jun 2023 16:15:09 -0400
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
Message-ID: <bd90d6c9-308d-1080-1ea6-a9f0a0f78421@nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uoQxlk-ItLEpSkFtzVBbGMpXPTo>
Subject: [DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 03 Jul 2023 06:06:24 -0000
Abstract (and Section 2): Please remove the acronym DRO and just use "operator". Section 3 (Introduction): The first two paragraphs of the Introduction can be removed. Section 4 (Time Recommendations) This section repeats a lot and could be cut. But a real issue I have is with recommending a hardcoded IP for NTP service lookup. There are other mechanisms available for getting a rough time estimate. For example, looking at the RRSIG of the SOA of the root zone, maybe augmented with a querying a semi random name in a large zone, eg .com and check the RRSIG on the NSEC(3) record. Another method could be to just disable validation and take the NTP dns entry without DNSSEC, and once proper time is obtained, flush the entire cache or restart the validator. To me, it seems anything is better than hardcoding an IP address. Upon demand: a DNSSEC validator operator ought to be able to perform any of the runtime actions upon demand, for instance, to help diagnose a service failure. I don't understand what this sentence is saying. Section 5: I'm not sure we want to recommend 5011 to operators for anything but the root zone (and maybe not even for that). Regardless, I think the entity needing to solve the freshness of TA issue is not the operator, but the domain that requires its own seperate TA. So lets say that .mil wants it internal resolvers to hardcode the .mil TA, it needs to provide the method for keeping their TA fresh. The operator merely needs to follow that published method. I'd say that would be out of scope for this document. This section should also discuss split-DNS deployments and how that affects TA's and how to avoid sending public answers to the private side and visa versa. Section 6: Negative Trust Anchor (NTA) represents the only permitted intervention in the resolving process for a DRO. Why shouldnt an operator be able to flush a zone to get rid of say, a bad RRSIG record in the cache to reduce the downtime caused by a deployment error on the authoritative server. Another common method is to allow records beyond their signature expiry time to be served while attempting to refresh the record in the background. NTAs are not the only permitted intervention. Section 7: A common concern DRO has is the consistency between the cached RRset with those published by the DNS system. DRO should not implement or deploy any non standard mechanism. [I-D.ietf-dnsop-ns-revalidation] is one of these mechanisms Is this draft saying to not implement I-D.ietf-dnsop-ns-revalidation ? In such a situation, the DRO should be able to remove the RRsets validated by the rogue DNSKEY - which may be done by flushing the full cache. Why flush the full cache? Why not just the subtree for which the DNSKEY is authoritative? Eg if DNSKEY nohats.ca. is rogue, why not just flush "nohats.ca." and everything below that? Section 8: a DNSSEC validator may be willing to estimate the impact of deprecating one signature scheme. I don't understand what this is trying to say, Section 9: I'm not sure if this is actionable at all. Its like telling me to read all my syslog of all my servers. It's just not going to happen. too many noisy logs and background attacks happening for me to respond. Section 10: I believe all of this should not be the responisbility of the operator, but of the DNS software. It should do the right thing. Section 11: A DRO should consider secure transport as a complementary element of its trust model. I strongly object to calling encrypted transport "secure transport" and thus implicitly calling unencrypted transport "insecure". With DNSSEC, there is no security issue with going over unencrypted transport. There might be a privacy issue, but not a security issue. Section 12: A DRO should consider how the DNS client will discover the encrypted resolver. We have a whole can of worms in the ADD WG about this. Not sure we should repeat those discussion in this draft. To ease the (even future) deployment of DDR, it is recommended that a DRO uses a global IP address for its unencrypted resolver. Most DNSSEC validators are behind NAT on their own private IP space. I dont think this draft should recommend those somehow get public IPs. Section 13: As a result, when the time is outside this period validation is disabled, and this could be used by an attacker to disable validation for example to poison the cache Why is validation disabled? Validation failure and ServFail means there is no attack possible. If for validation only the TTL and RRSIG lifetime is ignored, there is still no chance to poison the cache with anything other than the content of the cached record, which validated at the time of retrieval. an attacker being able to provide a rogue trust anchor is potentially This is not a very realistic attack. Using weak cryptography reduces the strength in the trust implemented by DNSSEC as it relied on cryptographic signatures. That is mostly a problem of authoritative servers. The validator has no choice but to either use the weak algorithm that is in use, or worse treat it as unsigned. So there isn't anything a resolver operator can do here. it is recommended a DRO relies on different vendors. While I understand the argument, a counter argument could be made too. By using different vendors, one becomes victim to all implementation bugs, instead of just the ones from one vendor. Which is better? Perhaps chaining two vendors would be better? Regardless, I think this recommendation is not very good for resolvers. It applies better to authoritative servers. the TLS communication enables the DNS client to trust the RRSets without performing a DNSSEC validation. I strongly object to saying that transport security can be used to replace data origin security. Encrypted DNS does not obsolete DNSSEC. The trust in a DNS resolver depends on multiple factors, but one significant concern is the ability of the DRO to perform a man in the middle attack and change on the fly the RRsets without the stub client being aware of it. Exactly! So you MUST RECOMMEND using DNSSEC to prevent this attack. Missing from this document: - Operator considerations with multiple resolvers in their network and how to best operate them - Experience of how we dealt with previous DNSSEC specific outages - Advise on how to debug/detect DNSSEC issues - Split DNS considerations - VPN considerations I don't think this document contains much valuable content for a DNSSEC operator. I think this document needs to have resolver vendors with their customer support experiences involved in evolving this document. Paul
- [DNSOP] Review of draft-ietf-dnsop-dnssec-validat… Paul Wouters
- Re: [DNSOP] Review of draft-ietf-dnsop-dnssec-val… Peter Thomassen