IETF Logo Mail Archive

[Acme] Re: Interactions between HTTPS RRs (rfc9460) and HTTP-01 DV

Benjamin Kaduk <kaduk@mit.edu> Wed, 16 April 2025 17:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: acme@mail2.ietf.org
Delivered-To: acme@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C54C51D30CA6 for <acme@mail2.ietf.org>; Wed, 16 Apr 2025 10:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYC-BUjoDyK0 for <acme@mail2.ietf.org>; Wed, 16 Apr 2025 10:59:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3EFAA1D30C7C for <acme@ietf.org>; Wed, 16 Apr 2025 10:59:12 -0700 (PDT)
Received: from kduck.mit.edu (c-73-235-241-23.hsd1.ca.comcast.net [73.235.241.23]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 53GHx5H7002674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Apr 2025 13:59:07 -0400
Date: Wed, 16 Apr 2025 10:59:05 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Erik Nygren <erik+ietf@nygren.org>
Message-ID: <Z__vC4BqjsdvOM7W@kduck.mit.edu>
References: <CAKC-DJiDx7onEahH7KcYHykzf7iqGbOgjKD45BNHcE+AmHgoWg@mail.gmail.com> <22779.1744755025@obiwan.sandelman.ca> <CAKC-DJhaAiepBjTyANko7v5cq0WxtUYVBnOAoFnQnwx-_sZYCw@mail.gmail.com> <1dfc3e86-2f99-4f47-9f5e-e18dd58eb746@cs.tcd.ie> <CAKC-DJgNYOrj5ULiTrwZV0K8OummJ8opRfyJ=DVCYgMdiSoxEg@mail.gmail.com> <CAL02cgS5VAP1kiLgKKwKs4PzFg0_H6kFUxpSoqQ4uOV5+uejMA@mail.gmail.com> <CAKC-DJiwY_oDg63moYmPQbSSSz=ThXnc-h=Gc7b4JJhfX8VU0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKC-DJiwY_oDg63moYmPQbSSSz=ThXnc-h=Gc7b4JJhfX8VU0Q@mail.gmail.com>
Message-ID-Hash: 6RASNMEDPHR2J6IHBRJOEVU2I2BZA4PN
X-Message-ID-Hash: 6RASNMEDPHR2J6IHBRJOEVU2I2BZA4PN
X-MailFrom: kaduk@mit.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-acme.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Richard Barnes <rlb@ipv.sx>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Richardson <mcr+ietf@sandelman.ca>, IETF ACME <acme@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Acme] Re: Interactions between HTTPS RRs (rfc9460) and HTTP-01 DV
List-Id: Automated Certificate Management Environment <acme.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/TFUefdbNGt7jhD6hNfMdB-dD_rg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Owner: <mailto:acme-owner@ietf.org>
List-Post: <mailto:acme@ietf.org>
List-Subscribe: <mailto:acme-join@ietf.org>
List-Unsubscribe: <mailto:acme-leave@ietf.org>

On Wed, Apr 16, 2025 at 12:44:32PM -0400, Erik Nygren wrote:
> So perhaps:
> 
> "(The HTTP client MUST NOT resolve and/or MUST ignore any HTTPS DNS RRs
> [RFC 9460].
>  It also MUST NOT automatically apply an HSTS behavior to auto-upgrade to
> the HTTPS scheme.)".  ?

A "MUST NOT ... and/or MUST ..." construction feels a bit clunky.  And we
might provide a direct reference for the HSTS behavior that we mean
(assuming that we're just talking about the RFC 9460 one), so perhaps:

"The HTTP client MUST ignore the presence and content of any HTTPS DNS RRs
[RFC 9460] for the domain name being verified.  This includes, but is not
limited to, a requirement that the HTTP client MUST NOT apply the strict
transport security behavior specified in Section 9.5 of [RFC9460]."

-Ben

v2.30.2 | Report a Bug | By Email | System Status