[DNSOP] Re: Secdir last call review of draft-ietf-dnsop-rfc7958bis-03
Klaas Wierenga <klaas@wierenga.net> Thu, 01 August 2024 19:48 UTC
Return-Path: <klaas@wierenga.net>
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 16B18C14F5E3 for <dnsop@ietfa.amsl.com>; Thu, 1 Aug 2024 12:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 mtJQCkUXS-Wf for <dnsop@ietfa.amsl.com>; Thu, 1 Aug 2024 12:48:40 -0700 (PDT)
Received: from out186-ams-ipv6.surfmailfilter.nl (out186-ams-ipv6.surfmailfilter.nl [IPv6:2001:610:188:173:192:87:106:186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75C2C14F70A for <dnsop@ietf.org>; Thu, 1 Aug 2024 12:48:39 -0700 (PDT)
X-Halon-ID: 09bb4eb3-503f-11ef-a258-005056a3df38
Received: from mail.het.net.je (unknown [2001:610:508:110:192:87:110:20]) by filter2-ams.surfmailfilter.nl (Halon) with ESMTPS id 09bb4eb3-503f-11ef-a258-005056a3df38; Thu, 01 Aug 2024 21:48:35 +0200 (CEST)
Received: from 217-123-25-125.cable.dynamic.v4.ziggo.nl ([217.123.25.125] helo=smtpclient.apple) by mail.het.net.je with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <klaas@wierenga.net>) id 1sZbmI-0000YN-VD; Thu, 01 Aug 2024 19:47:59 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Klaas Wierenga <klaas@wierenga.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 01 Aug 2024 21:48:24 +0200
Message-Id: <CB4ED5B4-B7DA-4CB1-A3EA-07571129D39F@wierenga.net>
References: <E5D49184-98BA-4515-9731-4EF5C915BED5@cloudflare.com>
In-Reply-To: <E5D49184-98BA-4515-9731-4EF5C915BED5@cloudflare.com>
To: Joe Abley <jabley@cloudflare.com>
X-Mailer: iPhone Mail (21F90)
X-Antivirus: no malware found
Message-ID-Hash: O3PZC2ZBB4NXQV3KZXV4FLF3XOXXKIBT
X-Message-ID-Hash: O3PZC2ZBB4NXQV3KZXV4FLF3XOXXKIBT
X-MailFrom: klaas@wierenga.net
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/6FVvIdKg3dZVNwapogUXGYRMmBA>
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 Joe, Sent from my iPhone > On 1 Aug 2024, at 21:11, Joe Abley <jabley@cloudflare.com> wrote: > > 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. True that it does not eliminate all risks, but I’d argue that the use of http instead of https leads to a much more trivial to exploit attack surface than your examples. > > 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. I think that position is reasonable, and I would be happy with such a sentence! Klaas > > > Joe >
- [DNSOP] Secdir last call review of draft-ietf-dns… Klaas Wierenga via Datatracker
- [DNSOP] Re: Secdir last call review of draft-ietf… Joe Abley
- [DNSOP] Re: Secdir last call review of draft-ietf… Klaas Wierenga
- [DNSOP] Re: [Ext] Secdir last call review of draf… Paul Hoffman