[secdir] Re: Secdir last call review of draft-ietf-dnsop-rfc7958bis-03

Joe Abley <jabley@cloudflare.com> Thu, 01 August 2024 19:11 UTC

Return-Path: <jabley@cloudflare.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D32C14E513 for <secdir@ietfa.amsl.com>; Thu, 1 Aug 2024 12:11:33 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
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 2d67L2Dhd7OB for <secdir@ietfa.amsl.com>; Thu, 1 Aug 2024 12:11:29 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4CDC169400 for <secdir@ietf.org>; Thu, 1 Aug 2024 12:11:29 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a7a9e25008aso979806166b.0 for <secdir@ietf.org>; Thu, 01 Aug 2024 12:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1722539488; x=1723144288; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KaE99hzOz9r95O/2/ZNtpS4xzvcJG+jfQtQolCqK3Rw=; b=JhIqTk8uwdkrUIpI3t5UQCSWF/y60Dp1xpjZ9NP3r2BylHTVhjC27HWW38g8OdrK/i vRKLNHBQsmx9g4uCMSVj5EY2YUsvG7r9hCVl8s2apMTKP3YrF0my93htU3lqGJDpAbYR fgZFy0mLtELSiYltyeKR1o6s3KB3dwJo4APtW+pqYEBkqvmEBIpulQnwFseac2KwuguY LuLpGJF4QMpxVP3M91pq8hB8gT+BT4GeQN5r9m2eYqLR0MmZu5MR2or6tQoQVYaJnuKT xaFJ6xjZiDsbqmlbgpJeNNBEFgdRupQJf4+N2t8gdVLoJi2+6K4cIH9Cc7eBLpZsk0P/ HStQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722539488; x=1723144288; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KaE99hzOz9r95O/2/ZNtpS4xzvcJG+jfQtQolCqK3Rw=; b=k8OFXostONj8dQKupaEHIjYPMrruHC21vuWAtm/xvOVi0mgymO7qC4kzDEXAGDv0X6 q/8nNCYBWtpNTS68DraT+KIJuDRMt1UcRXWve5O1sn/Gq+tuIelvF5NEYeUFJuAMfNui ZD2iUoVA4vHuhKfK5yhJWloRXMmuNFuKP6DKf3PHl30mJ1iMvtXMrvX1kPkmBli8b07g DclU3N9CHFpNtaKQ1YRvCyXkjpk5kgdY7FYtO1+7MSuMxeZz0KNKaj6MCFF0J71ZHlR3 QcdBIAluSbyE1IyR+0fV837GPP6JsVI0NLgce229TyW6gbUl87AbWMMAUip9qxisuIAh VK5Q==
X-Gm-Message-State: AOJu0Yz2XwgQGMds3tiepLV1EaChj1hkHKLPrC2VeYk7t/pxlukAeGol 6hYGZK50RIc+/uPmRatwIjJPQHmPzaTlw1wpLDGgtpfJxajXdUaNaBFYXNWQ+KE=
X-Google-Smtp-Source: AGHT+IFA2xiBKKUYEhYCvOhOQQbTOo8eNF4qesuw8HoQbKKRccw+DTnHWdCejja4E5J7c29WA/ydIw==
X-Received: by 2002:a17:907:724b:b0:a7a:a46e:dc39 with SMTP id a640c23a62f3a-a7dc4abf26fmr104814466b.0.1722539487970; Thu, 01 Aug 2024 12:11:27 -0700 (PDT)
Received: from smtpclient.apple ([2a09:bac1:5520::209:116]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9bc3bc1sm12891766b.44.2024.08.01.12.11.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2024 12:11:27 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Joe Abley <jabley@cloudflare.com>
In-Reply-To: <172253719755.2383132.16085097683731517707@dt-datatracker-659f84ff76-9wqgv>
Date: Thu, 01 Aug 2024 21:11:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5D49184-98BA-4515-9731-4EF5C915BED5@cloudflare.com>
References: <172253719755.2383132.16085097683731517707@dt-datatracker-659f84ff76-9wqgv>
To: Klaas Wierenga <klaas@wierenga.net>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: VNTJKYYVGTKPPXHLXCR6LQS2223VHOYN
X-Message-ID-Hash: VNTJKYYVGTKPPXHLXCR6LQS2223VHOYN
X-MailFrom: jabley@cloudflare.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: secdir@ietf.org, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-rfc7958bis.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [secdir] Re: Secdir last call review of draft-ietf-dnsop-rfc7958bis-03
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LYSt8UPd4Io6HCQvkw0bYSZcWkA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Hi Klaas,

On Aug 1, 2024, at 20:33, Klaas Wierenga via Datatracker <noreply@ietf.org> wrote:

> Reviewer: Klaas Wierenga
> Review result: Has Nits
> 
> The draft reads well and is clear. I have one question that is maybe worth
> answering in the security considerations. What is the impact of retrieving the
> trust anchors over http instead of https? Does that lead to a risk of ending up
> with an invalid set of trust anchors?
> 
> Klaas

There are risks of ending up with an invalid set of trust anchors regardless of what method is used to retrieve them. The use of TLS might mitigate some risks, but it does not eliminate them (e.g. it does not address the risk of a compromised CA issuing a certificate, or that the document being retrieved over HTTPS has been modified at rest by some unauthorised third party.

There are compensatory controls that can be used to mitigate particular risks, but the decision to mitigate particular risks and the choice of mitigation will surely vary significantly depending on the nature of the relying party. For some applications, trust-at-first-use might be perfectly appropriate. Others might require different measures to be taken. Some might consider retrieving the XML document described in this document to be too risky to do at all, and might insist on manual, in-person attestations and verification of new trust anchors before use.

I think it would be inappropriate for this document to try and catalogue all possible use-cases and risks around this. However, I can see how it might be useful to add a sentence saying this kind of thing out loud. I have not discussed this with my co-authors but I am interested to hear their reaction.


Joe