[Secdispatch] Please help dispatch "Dangerous Labels"

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 26 July 2022 15:09 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B04C13C534 for <secdispatch@ietfa.amsl.com>; Tue, 26 Jul 2022 08:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=aBAmUNsW; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Ju6P2kd6
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2vP9_H2B3za for <secdispatch@ietfa.amsl.com>; Tue, 26 Jul 2022 08:09:02 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0F4C14F6E5 for <secdispatch@ietf.org>; Tue, 26 Jul 2022 08:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1658848128; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=GJNTN/ujJLRyYS3LZljKYqJAPlqG7poHJQJOX0CFJbE=; b=aBAmUNsW8/sWllJT0uwEIxPCIlapM0DwslTgKBwYt/Xeg0G38MfpzmVrYuIBhWFijPdY1 Z9eNDP6WqEXSdnjDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1658848128; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=GJNTN/ujJLRyYS3LZljKYqJAPlqG7poHJQJOX0CFJbE=; b=Ju6P2kd6TUAnbFqNqMrfxxzhE+rCpL/qxJ+F9X1CBPTMZS0oeFixoAXWL2qJCTcakNCMC SlOMPjI4TW4OVKRU6VJ5aSck/xISeXylIfFHO2zutKzbAW2Ms9JpFZrDmQcBtfh2ntTRuok mOOxuXYP7bS1y2vQ5CMfK37OGmsNYWLkSm2Pr8s2DOLiHlnCbrnjMz2vGW1e27ml+xieqZF BrW2MAmK9YL8WgLNCa9GAv4raZ3dfwEcj+BZJdHYDe1FkyNoZ8utIXCg/jLZBX2RfWVd1iQ h9kk0Zvp8tsNvmK7qMW2yJPN1kHen6SDGWP9hx3mowh1u710L2vTHSxLeGRQ==
Received: from fifthhorseman.net (dhcp-8ab5.meeting.ietf.org [31.133.138.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 112ABF9AE for <secdispatch@ietf.org>; Tue, 26 Jul 2022 11:08:47 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id BFB2220CB9; Tue, 26 Jul 2022 11:08:42 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: secdispatch@ietf.org
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Tue, 26 Jul 2022 11:08:41 -0400
Message-ID: <87tu73q5c6.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/eR-yfrI3a09lZ_REJTr6sEOT8oQ>
Subject: [Secdispatch] Please help dispatch "Dangerous Labels"
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2022 15:09:07 -0000

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://datatracker.ietf.org/doc/draft-dkg-intarea-dangerous-labels/

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
hostmaster@example.com, 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://gitlab.com/dkg/dangerous-labels/

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