[DNSOP] 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: 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 B3771C14E513 for <dnsop@ietfa.amsl.com>; Thu, 1 Aug 2024 12:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 KSopImd67x5Q for <dnsop@ietfa.amsl.com>; Thu, 1 Aug 2024 12:11:29 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 ACD68C1522A0 for <dnsop@ietf.org>; Thu, 1 Aug 2024 12:11:29 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a728f74c23dso957996366b.1 for <dnsop@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=l38XLb+Y2Ge1tHR2chiwm2EucctJToMXgbFDXxAgipP44PbblgzPlThop2hc5olgKq bEx0tggNPfXREtXvxd+ecAlLSXL/cNTrbwsmrjv5v+CA0wkOslq0zzMcW2RdYaMifd3a 5Mg9NDka8qDwRs4B/6hKNBUvCClH9HzTbhTDYv9mJhnxGaeWvDKiBCPoK2izPkbywEYu KK1XrqfQKt3LBvvRSmnWy/8T4cZiUjSI1u/98UWvJ4HRyzKgZgzDUvRrg9krmvVno1HD IQwJPZOTT4w2ZI/fHQ08L0Fmh6kINJDk14egPGN4cUY9qsHg3aOfOpO6ZqtWL2gTKLMq PIBg==
X-Forwarded-Encrypted: i=1; AJvYcCWiYce5iuos28J1pYvP6ewz8u5BK80RGBABOw+Xuoklf0AEQFauLo/WYwcAU9D0cxAdvtYt1Y8BsQDsX51XGA==
X-Gm-Message-State: AOJu0YwdXIvGM3Nubz3zJ5uHpXzQ8KiJ8e6KVSq9pStQzduZljqVf8nO t7wmqkPNbb1sQ7n5rJ+9jbsbAbSIgl0xBHD15bN58us+fWmIV7Ke+P8Qz6jHC1fb09/RE7vmx3v S
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-dnsop.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: [DNSOP] Re: Secdir last call review of draft-ietf-dnsop-rfc7958bis-03
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cGwLEnstpAxuSDT8vkRjheMAyWc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-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