Internet DRAFT - draft-madeleine-explicit-domains-relations
draft-madeleine-explicit-domains-relations
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,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]
