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

[Stefan Grimminck <[e-mail]>]

Hi Eliot, and URI Review team,

Thank you for the technical feedback and for the acknowledgement of the utility in formalizing these operational conventions.
I want to clear up what might be a misunderstanding first. The "illegal characters in the scheme" framing may have given the impression that the draft proposes something like h**p (asterisk substitution). The actual canonical form in the current draft is [scheme] bracketing:

http://example.com/path -> [http]://example[.]com/path
mailto:[e-mail] -> [mailto]:user[@]example[.]com

Hopefully, your e-mail clients demonstrate this as well by not linkifying them :)

The opening "[" is not permitted in a URI scheme name per RFC 3986 Section 3.1, so the result cannot be confused with a valid URI or collide with any IANA registration. It scales to any scheme ([https], [ftp], [smb], [sftp]) without needing a per-scheme mapping table, and it is consistent with how the draft already handles dots and at-signs.

The legacy tokens hxxp and hxxps are documented as fielded but NOT RECOMMENDED for new output. The reason they are not recommended is that character substitution does not scale. Each scheme needs its own mapping and there is no predictable rule (sftp could become sfxp, sxtp or sxxp). Legacy substitution prevents deterministic de-obfuscation because distinct protocols like SMTP and SFTP could collapse into identical tokens, whereas bracketing ensures a unique, reversible mapping. Furthermore, a substituted string like hxxp still looks like a syntactically valid scheme name, meaning future protocol obfuscations could collide with existing registrations.

Bracket wrapping avoids these problems while standardizing how indicators are shared in a scalable way. Implementations are expected to recognize hxxp and hxxps during de-obfuscation for backward compatibility. Practitioners who already rely on hxxp can keep doing so, and tooling will handle both forms if the implementer chooses to.

Based on the review feedback, I'm planning the following changes for -09:

- Adding RFC 5891 (IDNA 2008) as a reference for the Internationalized Domain Names edge case. Appreciate the pointer, and correction that RFC 3490 is obsoleted by RFC 5891.

- 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.

Regarding the DISPATCH question: I presented a previous version of this draft to SECDISPATCH last April and received supportive feedback from Eric Rescorla, Rich Salz, and Andrew S2.

Thanks again for your time and expertise.

Best regards,

Stefan Grimminck

On Sunday, April 12th, 2026 at 11:42, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:

> Hi URI Review team,
>
> Thanks very much for your comments. Ted, in answer to your question, I am not aware that this work has been presented to the IETF. Stefan may do so if he wishes, and I would assist him if he wishes to see the work DISPATCHed. Stefan, please take note that at least one reviewer here prefers the way you originally approached the work, and revise as you see fit. Also, please take note of Martin's concerns below.
>
> Eliot
>
> ps: I will be unavailabe for the next two weeks. Expect responses after that point.
>
> On 11.04.2026 04:09, Martin J. Dürst wrote:
>
>> Hello Eliot, others,
>>
>> One detail that caught my eye is in https://www.ietf.org/archive/id/draft-grimminck-safe-ioc-sharing-08.html#name-step-3-host:
>>
>>>>>>
>> IPv6 addresses use colon-hexadecimal notation inside square brackets (e.g., "[2001:db8::1]"), which does not trigger auto-linking in typical software; the entire bracket-enclosed literal, including any dots within it (e.g., the dots in "::ffff:192.0.2.1"), MUST be left unchanged.
>>>>>>
>>
>> The part up to the semicolon is most probably true, but leaving this unchanged would make it more difficult to fix that. We shouldn't put additional blocks in front of IPv6 deployment and usage, even if they are small.
>>
>> An additional comment below.
>>
>> On 2026-04-11 01:09, Ted Hardie wrote:
>>
>>> Hi Eliot,
>>>
>>> As a meta-question was this draft brought to the IETF before going to the
>>> ISE? I don't see any record of it in places I would expect (DISPATCH,
>>> SAAG), but my records may be incomplete.
>>>
>>> After a quick read, this actually seems like something that the IETF should
>>> consider, as there are some aspects of it that probably need wider review.
>>> An example here is Section 9, which references how to handle IDNs. It
>>> describes punycode, but the overall IDNA standard should be referenced,
>>> probably especially RFC 3490, Section 3.1.
>>
>> Which is obsoleted by RFC 5890.
>>
>> Regards, Martin.
>>
>>> On the question related to the existing registration, RFC 7595 says:
>>>
>>> There must not already be an entry with the same scheme name. In
>>> the unfortunate case that there are multiple, different uses of
>>> the same scheme name, the Designated Expert can approve a request
>>> to modify an existing entry to note the separate use.
>>>
>>> I would first contact Hugo Salgado, the original registrant, to see if he
>>> would be willing to work with this author on the draft and to transfer the
>>> registration. Since the use is functionally the same (though the
>>> surrounding advice is different), I don't see a particular need to shift
>>> the registration, but if this is desired and the original registrant is
>>> unavailable, I believe the designated expert could invoke the clause above
>>> and add the new document.
>>>
>>> regards,
>>>
>>> Ted Hardie
>>>
>>> On Fri, Apr 10, 2026 at 4:38 PM Independent Submissions Editor (Eliot Lear)
>>> [<[e-mail]>](mailto:[e-mail]) 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> Uri-review mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]