Explicit bilateral relationship between domains

contact@yann-madeleine.com

General Internet Engineering Task Force Domains relationship User trust http headers 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

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

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

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.

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

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

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

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

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

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.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document should not affect the security of the Internet.

References Normative References

Contributors Thanks to all of the contributors.