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

Stefan Grimminck <contact@stefangrimminck.nl> Tue, 28 April 2026 08:31 UTC

Return-Path: <contact@stefangrimminck.nl>
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 69D1EE48F1A6; Tue, 28 Apr 2026 01:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777365104; bh=dTUvObWPFjOo0XW7zj+erd9QqV7yk4jtMADNnzmlbXg=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=vgwAQJ8zKMZp9GxZ9Fh4QrrdhNo+FwV1DanD/Xs4sXJp3EOFEHmIsq01EPIyPcijH 3JvZmvTspu/8h4X1GNJVob37WF07pcoAkGqbQjd0YzSOxlKvBretkuKmY753KSId8w RoCrHFdmSnPMTiZx1jNKJ7SjghtPeP2XSIKGJaRo=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001, TO_EQ_FM_DIRECT_MX=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=stefangrimminck.nl
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 mbExgcdtm7wW; Tue, 28 Apr 2026 01:31:43 -0700 (PDT)
Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch [185.70.43.17]) (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 311DCE48F1A1; Tue, 28 Apr 2026 01:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stefangrimminck.nl; s=protonmail; t=1777365101; x=1777624301; bh=NcpTwe/DmZQf6jAWWXDIaWt+gg7WVVzgC7q/CdqsNvQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dB/9o7jNDWqAPZVBvBSF+ccageLMfdIfQBmeIZmkCnltJOKR9QOo0ma9GZLH1ibiS Nvhs+SdkrNMfpmqwDXygl/qjfnMzKWajBHHKxnaWX+qqHgEqZRY5Df7LJUHfsnu9s4 OaUAYNNJy7lDQfM9jtOkXJ05K/6LcwWVDdQ9GAORgRta6f6PPpedpzbv/Z0qu6JSEV n4W95OFKHelDiYM0+LkOly7SVZmVIAlQfWMQDkII32MKRjVzSpAqtvzLTiD5/DBTtU 3aj5fHpnKM+tCI0hAIOu4IzsB5i09pWEZpFdaslBlyIwsbxzxnii2WMLCes60PsZjH M1qNQc2Zt9sPA==
Date: Tue, 28 Apr 2026 08:31:35 +0000
To: Stefan Grimminck <contact@stefangrimminck.nl>
From: Stefan Grimminck <contact@stefangrimminck.nl>
Message-ID: <prpBDWv9p7Cn_xwgagjm8vtIQtRWmJkyLoSHOoU2i-ejdU66R7YcmRt3FImTE9VE4NqIKN5eyBUoNjkV7hXDdm3FIR3HzINaG2KDoCwaeJw=@stefangrimminck.nl>
In-Reply-To: <DD6OFtYhxxdD33WnL1wWU5xfuQlJRq0CHuYopGRJjYQH35FzcC5Asnh1Gt6zCq5fod1pXl4bssbjeFTcmdLEJZONuHBb2CNPNWHOxcsUiCM=@stefangrimminck.nl>
References: <e100c374-1323-4e10-942e-7c956b46f9e3@rfc-editor.org> <CA+9kkMCs_eWXGcS5uScro7bRoFX=7AJq1o76W-8bCXp-K9-Hsw@mail.gmail.com> <070fe9bb-2c33-4c41-a1d6-06f7efa15491@it.aoyama.ac.jp> <ce84a0a1-f56a-479c-9052-328b9a4a4332@rfc-editor.org> <2Eq32vEqs9jQZEbb2Tup4mZm6PgHH2Xd9TB9jKh6JI9APoO8o2-Q5_jfumCa2F1lMVv5eFfVSVzYbZT2y4u4ejXdttFa9btZBfG2UopeCwI=@stefangrimminck.nl> <98bcc796-83b1-43cb-a654-ac75cf8d1a4c@it.aoyama.ac.jp> <DD6OFtYhxxdD33WnL1wWU5xfuQlJRq0CHuYopGRJjYQH35FzcC5Asnh1Gt6zCq5fod1pXl4bssbjeFTcmdLEJZONuHBb2CNPNWHOxcsUiCM=@stefangrimminck.nl>
Feedback-ID: 39848713:user:proton
X-Pm-Message-ID: 2d429d8d42b56c283778404e401a2f666c7febf5
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: AQA3MEFUXAVOBCX5FMMFXVPBBOHEXEP2
X-Message-ID-Hash: AQA3MEFUXAVOBCX5FMMFXVPBBOHEXEP2
X-MailFrom: contact@stefangrimminck.nl
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: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Ted Hardie <ted.ietf@gmail.com>, 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/q9Aex1Y7wKUkqMGkjccGOwxtjzo>
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>

Hi Eliot, Martin, and URI-review team,

Thank you again to everyone for the review of -08. I have published -09 incorporating the feedback from this thread:
https://datatracker.ietf.org/doc/draft-grimminck-safe-ioc-sharing/09/

The main changes:

1. IPv6 literals are now obfuscated (Step 3). Colons inside an IPv6 literal become "[:]", and any embedded IPv4 dots become "[.]". The outer brackets of an IP-literal are preserved because removing them would break RFC 3986 authority syntax.
Examples: "http://[2001:db8::1]:8080" becomes "[http]://[2001[:]db8[:][:]1]:8080"; bare "2001:db8::1" becomes "2001[:]db8[:][:]1".
2. The IDNA edge-case text in Section 9 now cites RFC 5890 explicitly.
3. The "does not trigger auto-linking" justification for leaving IPv6 untouched has been removed.

To validate the spec against real-world URL shapes, I built a Go reference implementation and ran it against the Web Platform Tests URL corpus (879 inputs):
https://github.com/StefanGrimminck/safeioc

CI run (per-item audit trail, see TEST section):
https://github.com/StefanGrimminck/safeioc/actions/runs/24891319062/job/72884133848

Thanks again, and looking forward to next steps.

Best regards,

Stefan Grimminck



On Saturday, April 18th, 2026 at 13:25, Stefan Grimminck <contact@stefangrimminck.nl> wrote:

> Hi Martin,
> 
> Thank you for the TR58 reference. Initially, I set out to codify existing behaviors, but it became clear that a lot of legacy mechanisms do not scale (e.g., character substitution). This led to documenting a path forward with the scheme bracketing seen in the current text.
> 
> I agree that this should include IPv6 to ensure consistency. It was initially omitted due to the currently low frequency of IPv6 occurrences and the existing use of brackets within IPv6 syntax. I am creating a test setup to validate a solution for IPv6 and will share results.
> 
> Best regards,
> 
> Stefan Grimminck
> 
> 
> On Tuesday, April 14th, 2026 at 11:00, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> 
> > Hello Stefan,
> >
> > First, please also have a look at https://www.unicode.org/reports/tr58/,
> > which may be relevant for your work.
> >
> > On 2026-04-13 18:33, Stefan Grimminck wrote:
> >
> > > Based on the review feedback, I'm planning the following changes for -09:
> >
> > > - Reframing the IPv6 rationale in Step 3. The text currently states that IPv6 "does not trigger auto-linking in typical software," which I agree should not be presented as a permanent justification. I plan to replace this with a technical rationale.
> >
> > Sorry to disagree, but this is NOT about justification. Why do you
> > obfuscase domain names and IPv4 literals, but not IPv6 literals? If
> > attacks with the former are possible, I'm sure attacks with the later
> > also should be possible, and obfuscation has to address this.
> >
> > Regards,    Martin.
> >
> >
> >
>