Re: [Secdispatch] [EXTERNAL] Please help dispatch "Dangerous Labels"

[Mike Ounsworth <[e-mail]>]

Wait, that is exactly what this draft is doing. Please disregard.

---
Mike Ounsworth

-----Original Message-----
From: Secdispatch <[e-mail]> On Behalf Of Mike Ounsworth
Sent: July 26, 2022 1:17 PM
To: Daniel Kahn Gillmor <[e-mail]>; [e-mail]
Subject: Re: [Secdispatch] [EXTERNAL] Please help dispatch "Dangerous Labels"

I love the concept of this draft, but I wonder of a draft is the right format? This list is likely to be ever-evolving.

It was suggested during SECDISPATCH (I think) that maybe an IANA registry of Dangerous Labels would be more appropriate; thereby if a future draft introduces a new dangerous label, then that should be indicated in its IANA Considerations to be added to the registry.

---
Mike Ounsworth

-----Original Message-----
From: Secdispatch <[e-mail]> On Behalf Of Daniel Kahn Gillmor
Sent: July 26, 2022 10:09 AM
To: [e-mail]
Subject: [EXTERNAL] [Secdispatch] Please help dispatch "Dangerous Labels"

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
I've written a document that tries to establish a registry of labels -- just DNS labels and e-mail local parts at the moment -- that have surprising security properties:

   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dkg-intarea-dangerous-labels/__;!!FJ-Y8qCqXTj2!aCAmiYQiMTV_HUnnPG_57Y5F3iUU4YDneMgNQKCCORx1pU16QQQ2S5GulE3ndMrgT4g0PcwmTCcJ6x3u2de_GTrbYqn3oi01r8_X3ZuXig$ 

The not-so-secret goal of the document is to *discourage* creation of new labels like this.  Or, rather, to discourage the creation of systems that treat certain "magic" labels as having special properties.

For example, if the administrators of "example.com" permit Jennifer to take control of "mta-sts.example.com", she can change the e-mail transport security properties of the entire zone.  Similarly, if the admins allow Roberto to have access to the e-mail address [e-mail], he can create an X.509 certificate for any host in the zone, due to the CA/B Forum's baseline requirements.  Take a look at the doc for other examples.

These dangerous labels are booby-traps for unwary administrators.

If someone is designing a system that would want to add a label to either of the registries that this document designs, it gives us an opportunity to try to divert them to using something better, such as a .well-known URL, an underscore-prefixed DNS label, or anything more principled.

If anyone knows of other dangerous labels that should be listed here (DNS labels, e-mail local parts, or even labels in other categories), feel free to reply directly to me, or open an issue or merge request on https://urldefense.com/v3/__https://gitlab.com/dkg/dangerous-labels/__;!!FJ-Y8qCqXTj2!aCAmiYQiMTV_HUnnPG_57Y5F3iUU4YDneMgNQKCCORx1pU16QQQ2S5GulE3ndMrgT4g0PcwmTCcJ6x3u2de_GTrbYqn3oi01r896Dg14Mg$ 

But if this document goes forward, it has an explicit ask for IANA to create the registries, so it probably would need to culminate in an RFC.
I have no idea where this document should live within the IETF.

Suggestions?

        --dkg
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

_______________________________________________
Secdispatch mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/secdispatch__;!!FJ-Y8qCqXTj2!aCAmiYQiMTV_HUnnPG_57Y5F3iUU4YDneMgNQKCCORx1pU16QQQ2S5GulE3ndMrgT4g0PcwmTCcJ6x3u2de_GTrbYqn3oi01r8-s28-OHg$