Re: [DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06

Peter Thomassen <peter@desec.io> Mon, 03 July 2023 07:27 UTC

Return-Path: <peter@desec.io>
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 D1292C14CE2F for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2023 00:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (2048-bit key) header.d=a4a.de
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 Ut2iydqtSyu8 for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2023 00:27:18 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E06C14CF18 for <dnsop@ietf.org>; Mon, 3 Jul 2023 00:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PZzrpjzTN676ln6Y5Xd9fPaMCr6NonRFuH6z7vF0MEo=; b=Yvr6q1D6ZDNmoS1NbkwPTBQz7E 6MeHggrDOf8kqVuxjcTEBFrg2QJa8jYVEg566Judr9xc5cv/QjE+Ee/ZceuTFMwr8tM4ThEuyFokW 5BmJZVhJT0nhpEO0yn8FTEbgycPf82E/2c9xkMaRXD2VF6fwNqfw6l6zosHYRmISrwO7mKu2Ba8Oh yMEqmdhfK7xteWeNkQk/Zpe83nRigvaV1KhUJpktKfClNqpJMqaXwNXDDZNaD6w2BxIgpEvpv3FaR eA1KT1Lu1aqtvwkpVmi3eFs/puyohL/aG2F4d5qpf29l58snXcIgSxJ6/4bSFeOMXjqrfc4dCcYkB nlJWlKZg==;
Received: from [91.65.198.147] (helo=[192.168.178.70]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1qGDxr-00Btzg-4t; Mon, 03 Jul 2023 09:27:15 +0200
Message-ID: <740a6941-97db-0746-7ce2-6aefb59cda86@desec.io>
Date: Mon, 03 Jul 2023 09:27:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
References: <bd90d6c9-308d-1080-1ea6-a9f0a0f78421@nohats.ca>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <bd90d6c9-308d-1080-1ea6-a9f0a0f78421@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dJgmszMe251zPUuxiiz3SxC7iRY>
Subject: Re: [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 07:27:23 -0000


On 6/30/23 22:15, Paul Wouters wrote:
> Section 13:
[...]
>      an attacker being able to provide a rogue trust anchor is potentially
> 
> This is not a very realistic attack.

The same section says:

    On the other hand,
    mishandling Trust Anchor is likely resulting in a validator unable to
    validate most of the traffic under the TA.

I don't think this argument is particularly relevant, as an attacker with write access to the trust anchors would likely not replace any existing legitimate ones, but rather add the rogue one so that compromised traffic can be injected without causing validation errors otherwise.

> 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.
Noting that only one of the people supporting adoption back in 2020 and offering reviews have contributed such reviews in the last three years (if I looked correctly), and considering that most feedback in the last 12 months has been in opposition to many of the recommendations given in the document (including several times due to serious inaccuracies about how DNSSEC works), I'm wondering if it is still on track.

The draft was born almost 10 years ago and adopted more than three years ago; still, as Paul said, it's not clear that it contains much valuable content for a DNSSEC resolver operator. Perhaps the WG should consider abandoning it (although I'm not sure about the process).

Best,
Peter

-- 
https://desec.io/