[Uri-review] Re: draft-grimminck-safe-ioc-sharing

Frank Denis <ietf@pureftpd.org> Fri, 10 April 2026 16:01 UTC

Return-Path: <ietf@pureftpd.org>
X-Original-To: uri-review@mail2.ietf.org
Delivered-To: uri-review@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5A773D99B8DF; Fri, 10 Apr 2026 09:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775836912; bh=8PwWFg+SSliHEyGnURI69F2PS+YmVEd44sekBuWkQno=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=uqT9LHJHU3CCYfU8Y5Q2T9p/moz7o87RZWzIy8cEwg+/e99MODikBdRk+mc9bshDf xef+0JgQS9gOcXPrWqUXJxh2/Nsy99co44/4K8mGpmd8OCG7gEvOHAnc1rBGbRDWAl duFMS7WAlooMak0DgpdNGE1TO4hPpm8OxBmupdmg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=pureftpd.org; domainkeys=pass (2048-bit key) header.from=ietf@pureftpd.org header.d=pureftpd.org
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 upZX2wHpvAWA; Fri, 10 Apr 2026 09:01:51 -0700 (PDT)
Received: from mailout-uk.mx.c9x.org (mailout-uk.mx.c9x.org [137.74.223.233]) (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 mail2.ietf.org (Postfix) with ESMTPS id 36429D99B8D4; Fri, 10 Apr 2026 09:01:50 -0700 (PDT)
Received: from msync.c9x.org (localhost [127.0.0.1]) by msync.c9x.org (OpenSMTPD) with ESMTP id 39b8658a; Fri, 10 Apr 2026 18:01:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pureftpd.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bp5OgWW8ITNIwhp2BJNT38RX4+w=; b= w/N7+Mu+H3X9zS7Fcktg/tESf95TNe4PRMXZv2RoPFbTEla5XZ9j6LxdrZG0sP1L Ft22owj2DDiPR/egrjyh2+r+dEzVNyw9AlCDscGfvnMDNp93O+9g35GB2/vX14qH O0bgo8miG1oQbwPCof1uDWAbyJ32DzC74Mt4jBeC2jGPh0SwZ0OOqQxUeo66ss0Z XYaEEMgbxhD6GOnbFW5QQ0rwKonIf0lwomuz+94nzfJ/b1Hm3tzbBOuSk2Iy4H0V XmE99M3HP0AcoNMXqRRXb8fpK7khknDC7sMLyrqm83Mllizatzoh6aaPhc/6Rbuz O9ZwaO1A5zaGeWeVfTXcxw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pureftpd.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=05DQm+WdseeZisTNf387ePl ooWJCb88lNUVijoSzDt9AfmA6UkHnoV3OhmhkshfmkeZverwEOQsHFh7D/CR0OaZ RyAuuCOSAW/aJc8pVeeUDJolb5RNG2zQZzTaYiHWaNbSEwm63nhjOVCvwjgYYStV X6l5NVb1PFP61103wAIn/kR8aAZEpyyxWYCRQD1vfKU/t1DquLAEQJKB4BDOMnGX Iq/7GxIR26YMlZJArO8FlUW/a6O4NF9bokLJj2m9KKWhOvkUBSX0VDtHqVg3cMFD SCu0BPGRyg0HqRiP/+c5lcTiKM7tRPVbSW6jgNIbG9bztoAi/tLAeT9j8SAzJ6Q= =
Received: from smtpclient.apple (bne75-2_migr-82-66-97-28.fbx.proxad.net [82.66.97.28]) by premiere.mx.c9x.org (OpenSMTPD) with ESMTPSA id 7c97bd69 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Fri, 10 Apr 2026 18:01:41 +0200 (CEST)
From: Frank Denis <ietf@pureftpd.org>
Message-Id: <1FF4E750-6228-45F5-B6BF-6034B6896971@pureftpd.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7DA12C46-FC5E-46E4-BDE5-F9D286AF7BFA"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.1\))
Date: Fri, 10 Apr 2026 18:01:29 +0200
In-Reply-To: <e100c374-1323-4e10-942e-7c956b46f9e3@rfc-editor.org>
To: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
References: <e100c374-1323-4e10-942e-7c956b46f9e3@rfc-editor.org>
X-Mailer: Apple Mail (2.3864.600.1)
Message-ID-Hash: XXPS6JT7GVQ754SIQFBHVMROI4EAH5A4
X-Message-ID-Hash: XXPS6JT7GVQ754SIQFBHVMROI4EAH5A4
X-MailFrom: ietf@pureftpd.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-uri-review.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: uri-review@ietf.org, draft-grimminck-safe-ioc-sharing@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Uri-review] Re: draft-grimminck-safe-ioc-sharing
List-Id: Proposed URI Schemes <uri-review.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/lDPHa77e4Mzdk1ypZHxmGa20wYM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Owner: <mailto:uri-review-owner@ietf.org>
List-Post: <mailto:uri-review@ietf.org>
List-Subscribe: <mailto:uri-review-join@ietf.org>
List-Unsubscribe: <mailto:uri-review-leave@ietf.org>

H,

Using hxxp/https when sharing IoCs is already a widely adopted practice, and I think it would make sense to formalize it through a permanent registration.

Thanks to Stefan for suggesting this.

As for using illegal characters, that may not be desirable.

First, because it is very uncommon, and security researchers are likely to keep using the conventions they already rely on, which would make the registration effectively useless.

Second, these special characters are likely to break a number of URI parsers. I do not see any advantage compared with the original proposal.

-Frank.


> On 10 Apr 2026, at 17:37, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> wrote:
> Dear URI reviewers,
> 
> The Independent Submissions Editor has received a publication request for draft-grimminck-safe-ioc-sharing.  This draft intentionally makes certain URIs unresolvable during transport.  I am contacting you because there are several legacy use cases, two in particular: http-> hxxp and https -> hxxps.  I have no doubt, but that these indicators of compromise (IOC) transformations are widely accepted as a convention.  I note that an old draft, draft-salgado-hxxp-01 has provisionally registered these schemes.  This is sufficient to limit damage with those particular schemes.  There can be other schemes that may be used to reference compromised content.
> 
> I have several questions for this group:
> 
> Stefan is considering a more generic approach that uses illegal characters in the scheme (*) for other schemes.  Do you agree that is appropriate?
> Would you like the registration for hxxp and hxxps to move to this work, should it progress?
> Would you like to mark the registrations as permanent as part of that process?
> Would you like to perform a review of the draft?  Reviewer guidance can be found at https://www.rfc-editor.org/materials/reviewer.guide.txt.
> Regards,
> 
> Eliot
> 
> 
> 
> _______________________________________________
> Uri-review mailing list -- uri-review@ietf.org
> To unsubscribe send an email to uri-review-leave@ietf.org