Internet-Draft Explicit relationship between domains November 2022
Madeleine Expires 19 May 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-madeleine-explicit-domains-relations-00
Published:
Intended Status:
Informational
Expires:
Author:
Y. Madeleine, Ed.

Explicit bilateral relationship between domains

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.

▲

Table of Contents

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.

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

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

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.

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.

Table 1
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

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

Table 2
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 3
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

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

Table 4
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

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Contributors

Thanks to all of the contributors.

Guillaume Metayer

Author's Address

Yann Madeleine (editor)