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

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Greetings Graham,

It's early days and we're just seeking for direction at this point.

Thanks,

Eliot


On 13.04.2026 12:49, Graham Klyne wrote:
> A small point:  rather  than simply asking IANA to reserve the legacy 
> hxxp(s), it might be easier (for them) to include actual registration 
> templates, complete with rationale.  For example, along the lines of 
> https://www.iana.org/assignments/uri-schemes/historic/drop (with a 
> different description).
>
> #g
>
> (Added Mark Baker cc as current IANA reviewer)
>
> Sent from my iPhone
>
>> On 13 Apr 2026, at 10:33, Stefan Grimminck 
>> <contact=[e-mail]> wrote:
>>
>> 
>>
>> 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> -> 
>>  [http]://example[.]com/path
>> mailto:[e-mail] <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]> 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]
>>>>
>>
>> _______________________________________________
>> Uri-review mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]