Internet Engineering Task Force Y. Madeleine, Ed. Internet-Draft 15 November 2022 Intended status: Informational Expires: 19 May 2023 Explicit bilateral relationship between domains draft-madeleine-explicit-domains-relations-00 Abstract Good practices of domain handling are often overseen, making it difficult for users to know if a domain is legitimate, this proposal aims to create an easy, accessible way to verify relations between domains and by extension entities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 May 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Madeleine Expires 19 May 2023 [Page 1] Internet-Draft Explicit relationship between domains November 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Owning relations . . . . . . . . . . . . . . . . . . . . 4 3.2. Delegated relations . . . . . . . . . . . . . . . . . . . 5 3.3. Operated relations . . . . . . . . . . . . . . . . . . . 6 4. Caching, duration and revocation. . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Domains are a common vector of attack, this is due in partly to the non comprehension of what a URL is, but also due to the lack of good domain handling. Mastercard for example uses mastercard.com as a global entry, mastercardcontentexchange.com for newsroom, mastercardservices.com for services. National Bank of Canada (one of Canada's biggest banks) uses bnc.ca, nbc.ca, banquenationale.com, bncd.ca, nbdb.ca, nbfwm.ca, fbngp.ca, bntmaretraite.com, nbfm.ca, bnmf.ca, assurances-bnc.ca, nbc- insurance.ca depending of the language and the offer. Equifax uses equifaxbreachsettlement.com for the settlement of its data breach and that domain has been infamously squatted. How can we legitimately hope that a normal user can tell apart a domain like bncd.ca and bnc.bank or spot a variation in a domain like equifaxbreachsettlement.com ? As it's nearly impossible to create a system that insures who owns what domains, and as hoping for correct domain handling is day dreaming. This draft will try to actually create explicit links between domains allowing browser vendors to give the user information that will help them defining if a domain is actually related to a trusted domain. Madeleine Expires 19 May 2023 [Page 2] Internet-Draft Explicit relationship between domains November 2022 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Definition To help tackle the domains relation in a way that is standard fair to small and big player and non government related, this draft proposes to use a new dedicated http header to establish the relation. This header will be set on both the claiming domain and the trusty domain. The new header MUST only be available on secured connections (https) to mitigate their alteration by an adverse party, they also MUST be non accessible/forbidden to javascript or fetch. The header is of the following form REL: RELATION; DOMAIN * rel: own; https:www.equifaxbreachsettlement.com * rel: claim; https://equifax.com Only one REL header with a claim relation should be present in a response, multiple REL headers with non claim relation can be sent with a response. Each REL header should define only one relation to a domain, subdomain or subdirectory. The claiming relation MUST use the claim relation, the trusty can use one of the defined relations: own The related domain is entirely owned and operated by the same entity as the domain exposing the relation delegate The related domain or subdomain is handled by an entity to which the owner of the exposing domain as delegated the rights to operate under its name, for example a support platform operate The related domain/subdomain/subdirectory is owned by a third party, but operated by the owner of the domain exposing the relation, this is usually the case for a social profile Madeleine Expires 19 May 2023 [Page 3] Internet-Draft Explicit relationship between domains November 2022 3. Validity All relationships MUST be direct if a transitive relation is found it should be ignored so A <---> B is OK but A <---> B <----> C will only expose the relation between A and B This will both avoid some circular relationships and mitigate the use of a compromised trusted intermediate to fake a relation. * All relationships MUST be sent in non redirected responses, every 3XX HTTP responses MUST be resolved before interpreting the REL header. * All relationships MUST be exposed on HEAD, GET and OPTIONS methods and SHOULD be exposed on the other HTTP methods. * A relation is valid for the domain/subdomain/subdirectory depending on the type of relation and the expressed domain The claim relation MUST be on a domain with no subdomain, the request will then be resolved to the main subdomain for the domain, this prevents the use of a delegated subdomain into a claim. For example www.badactor.test can not claim actor.supportplatform.test as it would imply a relation to supportplatform if that platform was allowing its users to add some headers on their pages 3.1. Owning relations An owning relation can only be linked to a full domain, and therefore the domain definition MUST be of the type REL: own; https:*.DOMAIN.TLD so every subdomains, every subdirectory of DOMAIN.TLD should be considered as owned by the same entity as the domain exposing the relation. Madeleine Expires 19 May 2023 [Page 4] Internet-Draft Explicit relationship between domains November 2022 +====================================+ | rel: own; https://*.domain.tld | +============================+=======+ | URI | Valid | +============================+=======+ | https://www.domain.tld | TRUE | +----------------------------+-------+ | https://domain.tld | TRUE | +----------------------------+-------+ | https://sub.domain.tld | TRUE | +----------------------------+-------+ | https://sub.domain.tld/dir | TRUE | +----------------------------+-------+ | https://domain.tld/dir | TRUE | +----------------------------+-------+ | https://sub.sub.domain.tld | TRUE | +----------------------------+-------+ Table 1 3.2. Delegated relations A delegated relation can only be linked to a full domain or a subdomain, and therefore the domain definition MUST be one of * REL: delegate; https://*.DOMAIN.TLD so every subdomains, every subdirectories of DOMAIN.TLD should be considered as owned by the same entity as the domain exposing the relation. * REL: delegate; https://DOMAIN.TLD no subdomain but every subdirectories of DOMAIN.TLD should be considered as owned by the same entity as the domain exposing the relation. * REL: delegate; https://SUB.DOMAIN.TLD only the subdomain SUB and its subdirectories are considered as owned by a trusted third party Madeleine Expires 19 May 2023 [Page 5] Internet-Draft Explicit relationship between domains November 2022 +=======================================+ | rel: delegate; https://sub.domain.tld | +===============================+=======+ | URI | Valid | +===============================+=======+ | https://www.domain.tld | FALSE | +-------------------------------+-------+ | https://domain.tld | FALSE | +-------------------------------+-------+ | https://sub.domain.tld | TRUE | +-------------------------------+-------+ | https://sub.domain.tld/dir | TRUE | +-------------------------------+-------+ | https://domain.tld/dir | FALSE | +-------------------------------+-------+ | https://sub.sub.domain.tld | FALSE | +-------------------------------+-------+ Table 2 +====================================+ | rel: delegate; https://domain.tld | +============================+=======+ | URI | Valid | +============================+=======+ | https://www.domain.tld | FALSE | +----------------------------+-------+ | https://domain.tld | TRUE | +----------------------------+-------+ | https://sub.domain.tld | FALSE | +----------------------------+-------+ | https://sub.domain.tld/dir | FALSE | +----------------------------+-------+ | https://domain.tld/dir | TRUE | +----------------------------+-------+ | https://sub.sub.domain.tld | FALSE | +----------------------------+-------+ Table 3 3.3. Operated relations An operated relation can only be linked to a domain a subdomain or subdirectory, and therefore the domain definition MUST be one of * REL: operate; https://*.DOMAIN.TLD so every subdomains, every subdirectories of DOMAIN.TLD should be considered as owned by the same entity as the domain exposing the relation. Madeleine Expires 19 May 2023 [Page 6] Internet-Draft Explicit relationship between domains November 2022 * REL: operate; https://DOMAIN.TLD no subdomain but every subdirectories of DOMAIN.TLD should be considered as owned a trusted third party. * REL: operate; https://SUB.DOMAIN.TLD only the subdomain SUB and its subdirectories are considered as owned by a trusted third party. * REL: operate; https://SUB.DOMAIN.TLD/DIR/SUBDIR only the subdirectory SUB/SUBDIRECTORY found under SUB.DOMAIN.TLD/ and its subdirectories are considered as owned by a third party but operated by the trusted entity. +=============================================================+ | rel: operate; https://sub.domain.tld/directory/subdirectory | +=====================================================+=======+ | URI | Valid | +=====================================================+=======+ | https://www.domain.tld | FALSE | +-----------------------------------------------------+-------+ | https://domain.tld | FALSE | +-----------------------------------------------------+-------+ | https://sub.domain.tld | FALSE | +-----------------------------------------------------+-------+ | https://sub.domain.tld/dir | FALSE | +-----------------------------------------------------+-------+ | https://domain.tld/dir | FALSE | +-----------------------------------------------------+-------+ | https://sub.sub.domain.tld/dir/subdir | FALSE | +-----------------------------------------------------+-------+ | https://domain.tld/dir/subdir | FALSE | +-----------------------------------------------------+-------+ | https://sub.domain.tld/dir/subdir | TRUE | +-----------------------------------------------------+-------+ | https://sub.domain.tld/dir/subdir/leaf.html | TRUE | +-----------------------------------------------------+-------+ | https://sub.domain.tld/dir/subdir/lastdir | TRUE | +-----------------------------------------------------+-------+ Table 4 Madeleine Expires 19 May 2023 [Page 7] Internet-Draft Explicit relationship between domains November 2022 4. Caching, duration and revocation. The REL header MAY be cached for the duration of a session but SHOULD NOT be cached for a longer time, this will make sure the relation between the 2 domains is always relevant and allow for fast response in case of exploit on one of the domains. The revocation of a relation can be unilateral by any of the domains and is just a matter of not sending the header. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations This document should not affect the security of the Internet. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Contributors Thanks to all of the contributors. Guillaume Metayer Author's Address Yann Madeleine (editor) Email: contact@yann-madeleine.com Madeleine Expires 19 May 2023 [Page 8]