[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                         A. Brotman
Internet-Draft                                              Comcast, Inc
Intended status: Standards Track                              S. Farrell
Expires: August 29, 2019                          Trinity College Dublin
                                                       February 25, 2019


                         Related Domains By DNS
                         draft-brotman-rdbd-00

Abstract

   This document outlines a mechanism by which a registered domain can
   create a relationship to a different registered domain, called
   "Related Domains By DNS", or "RDBD".

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 http://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 August 29, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Brotman & Farrell        Expires August 29, 2019                [Page 1]


Internet-Draft                    RDBD                     February 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DNS Record for Secondary Domain . . . . . . . . . . . . . . .   3
   3.  DNS Record for Parent Domain  . . . . . . . . . . . . . . . .   4
   4.  Validation  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Steps to validate . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     6.1.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Lookup Loops  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Creating a Signature for the Secondary Domain  . . .   6
     A.1.  Sample Signature  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [[There's a github repo for this -- issues and PRs are welcome there.
   <https://github.com/abrotman/related-domains-by-dns>

   Current issues include:

   o  #1: use TXT or new RR?  (ATB: new RR, but TXT for now)

   o  #2: stick with a 1:n thing or design for m:n relationshops (ATB:
      m:n is possible (I believe) as it stands, using selectors)

   o  #3: include an indicator for the kind of relationship or not?

   o  #4: "h=" is wrong for a signature, but "s=" is selector, bikeshed
      later

   o  #5: specify input for signing more precisely - e.g. is there a CR
      or NULL or not ]]

   Determining relationships between registered domains can be one of
   the more difficult investigations on the Internet.  It is typical to
   see something such as "example.com" and "dept-example.com" and be
   unsure if there is an actual relationship between those two domains,
   or if one might be an attacker attempting to impersonate the other.
   In some cases, anecdotal evidence from places such as DNS or WHOIS/
   RDAP may suffice.  However, service providers of various kinds may
   err on the side of caution and mark the secondary domain being
   untrustworthy or abusive because it is not clear that they are in
   fact related.  Another possible use case could be where a company has



Brotman & Farrell        Expires August 29, 2019                [Page 2]


Internet-Draft                    RDBD                     February 2019


   two websites in different languages, and would like to correlate
   their ownership more easily, consider "example.at" and "example.de"
   registered by regional offices of the same company.  A third example
   could be an acquisition where both domains continue to operate.

   Using "Related Domains By DNS", or "RDBD", it is possible to indicate
   that the secondary domain is related to the primary domain.  This
   mechanism is modelled on how DKIM [RFC6376] handles public keys and
   signatures - a public key is hosted at the parent domain
   ("example.com") and a reference from the secondary domain ("dept-
   example.com") contains a signature (verifiable with the "example.com"
   public key) over the text representation ('A-label') of the primmary
   and secondary domain names.

   RDBD is intended to demonstrate a relationship between registered
   domains, not individual hostnames.  That is to say that the
   relationship should exist between "example.com" and "dept-
   example.com", not "foo.example.com" and "bar.dept-example.com".

   There already exists Vouch By Reference (VBR) [RFC5518], however this
   only applies to email.  RDBD could be a more general purpose solution
   that could be applied to other use cases, as well as for SMTP
   transactions.

   This document describes the various options, how to create a record,
   and the method of validation.

1.1.  Terminology

   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
   [RFC2119].

   The following terms are used throughout this document:

   o  Parent domain: This refers to the domain that is to be referenced,
      such as "example.com".

   o  Secondary domain: This will refer to the domain that references
      the parent domain, such as "dept-example.com".

2.  DNS Record for Secondary Domain

   There are a few options when publishing the reference to the parent
   domain.

   o  "v": Version string, which should be set to "RDBD1".



Brotman & Farrell        Expires August 29, 2019                [Page 3]


Internet-Draft                    RDBD                     February 2019


   o  "d": The Parent Domain.  This should be in the form of
      "example.com".

   o  "s": The selector, which is the same as defined in [RFC6376] and
      used to denote which published public key should be used.

   o  "h": The base64 encoded signature over the primary and secondary
      domain namess, created using the private key.

   A sample TXT record for "dept-example.com" would appear as:

   "v=RDBD1;s=2018a;d=example.com;
   h=TkKgbCV7xXWYES+I5y8KRvgQet7SOLUYTbJtjVyb2/H/
   phI4EcalpxhDfADPgCRwxASztR12BMq0 MLWJZZYxN1zuBE3joFED7EHRoDlFQti/
   GtRFg9lyOSLac58dyty3rdU2oLDSubbk21YYZZV7VsUh OqbGxrhe6LdY0f59aw7cGg2R
   +YIX0dW9z+I3cOcZKtdlfea42AS6sL4vJBy+ytWmfJC62wDL5IT3 HDmWVEmZg7GcSbT0
   62zQBUX0Xo3sDOquXyA2qzat4Gbq3FJeSTFEc3UQipHFBohb0qIkbWv2IeHC
   m2nYjnaCi8P9o3y2nBn1rfzuHB2ctPnnTqK+eg=="

   The input to signing is:

   s=dept-example.com&p=example.com

   Where:

   s: The secondary domain p: The primary domain

   For internationalised domain names, the punycode ('A-label') version
   is the input to signing.

3.  DNS Record for Parent Domain

   o  "v": Version string, which should be set to "RDBD1".

   o  "s": The selector, which is the same as defined in [RFC6376] and
      is a string used to denote a specific public key published by the
      Parent Domain.

   o  "k": The public key published for this selector, encoded using
      base64.

   A sample TXT record for the parent domain of "example.com":

   "v=RDBD1;s=2018a;
   k=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2LNjBAdNAtZOMdd3hl
   emZF8a0onOcEo5g1KWnKzryDCfH4LZkXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8
   Ly9ztBXc4obY5wnQpl4nbvOdf6vyLy7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERl
   QL6MDWLU9ZSWlqskzLVPgwqtT80xchU65HipKkr2luSAySZyyNEf58pRea3D3pBk



Brotman & Farrell        Expires August 29, 2019                [Page 4]


Internet-Draft                    RDBD                     February 2019


   Ly5hCDhr2+6GF2q9lJ9qMopd2P/ZXxHkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQ
   fVwrs4495a8OUkOBy7V4YkgKbFYSSkGPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIq
   Tj1QIDAQAB"

   And the TXT location for this record would be:

   "2018a._rdbd.example.com"

   This is constructed by using the selector (s=) in the secondary
   domain's reference to the first domain.  The absence of the record in
   this location MUST be considered a failure to validate, and a failure
   to establish the relationship.

4.  Validation

   The validated signature is solely meant to be evidence that the two
   domains are related.  The existence of this relationship is not meant
   to state that the data from either domain should be considered as
   more trustworthy.

5.  Steps to validate

   A validating system should use the combination of the Secondary
   Domain name and public key from the Parent Domain record to be able
   to verify the signature that is stored in the record for the
   Secondary Domain.  This is demonstrated in the appendix.

6.  Security Considerations

6.1.  DNSSEC

   RDND does not require DNSSEC.  It could be possible for an attacker
   to falsify DNS query responses for someone investigating a
   relationship.  Conversely, an attacker could delete the response that
   would normally demonstrate the relationship, causing the
   investigating party to believe there is no link between the two
   domains.

   Deploying signed records with DNSSEC should allow for detection of
   either attack.

6.2.  Lookup Loops

   It's conceivable that an attacker could create a loop of lookups,
   such as a.com->b.com->c.com->a.com or similar.  This could cause a
   resource issue for any automated system.  A system SHOULD only
   perform three lookups from the original domain
   (a.com->b.com->c.com->d.com).  The Secondary and Parent SHOULD



Brotman & Farrell        Expires August 29, 2019                [Page 5]


Internet-Draft                    RDBD                     February 2019


   attempt to keep the link direct and limited to a single lookup, but
   it is understood this may not always be possible.

7.  References

7.1.  Normative References

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

7.2.  Informative References

   [RFC5518]  Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
              Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009,
              <https://www.rfc-editor.org/info/rfc5518>.

Appendix A.  Creating a Signature for the Secondary Domain

   Appendix C of [RFC6376] has some reference material on how to create
   a set of keys for use in this type of use case.  The key length is
   recommended to be at least 2048 bits instead of the 1024 recommended
   in that appendix.

A.1.  Sample Signature

   Creation of keys:

   openssl genrsa -out rsa.private 2048 openssl rsa -in rsa.private -out
   rsa.public -pubout -outform PEM

   Keys in use:

   rsa.private: -----BEGIN RSA PRIVATE KEY-----
   MIIEowIBAAKCAQEA2LNjBAdNAtZOMdd3hlemZF8a0onOcEo5g1KWnKzryDCfH4LZ
   kXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly9ztBXc4obY5wnQpl4nbvOdf6vyLy
   7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL6MDWLU9ZSWlqskzLVPgwqtT80xch
   U65HipKkr2luSAySZyyNEf58pRea3D3pBkLy5hCDhr2+6GF2q9lJ9qMopd2P/ZXx
   Hkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfVwrs4495a8OUkOBy7V4YkgKbFYSSk
   GPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj1QIDAQABAoIBAH/eAgwrfq6w4/0X
   Bgk4iQ9q6vnWpQCvW5Z40jRq+MnsnshKPrVL+krIGU/fvt7vaIzIPFTGrf7VWxl3
   +oZg/1sRFPYUItjaluqjaxEhWvHH1saYCb2lAV1x9QtkgjBv4F6GZqfi1MJfro32
   QP36s/hIaVjdHHNsB7BkDgr6VEVIR5y2PmW4aLjHCiqsyDIUM4zRcl4exzw+rst1
   z2seOhhJrnYdc+VnkEg5GKENldZ3tZoY3je/OsfNJtKjpArPRqkP1qve3h3uD+PK
   obZ7BM+xok29Fxf6AgC99eDr9BatTa/a8q7NYMkVRLq/JdOF1XUuDDNd3r93Ae4n
   54qqucECgYEA/Xuct8ALG2/6Kd4Lmm9i055LVxdwB+1wG1JNE1IB+OI+6B8W49po vK/
   fFVHMEV2BoRr4EB58Xxa+oICBImIzTUQXYQnMbDzL2N+X3FrkDSGCPZQy7GzD



Brotman & Farrell        Expires August 29, 2019                [Page 6]


Internet-Draft                    RDBD                     February 2019


   wFdpY3ceNShou1bRt4/hPWLLI35ZXM3yqBJeGhbTUmYVdWrkXTNo2wUCgYEA2tpE
   +bg9iIYUJAg/CEpdWn+8ZxhRnBDziN88Grli+arSWaMWE809GyPaeiplbwywnXRb
   vliskE43CcgstnhRKY8dWB2AQnRESvsJKO8rw/ONSxlWTpFc78xxmmNSvOBs4Srv
   quMc6HTMaetCM5/l0PddCY3/rls9FTESf36RXpECgYEA5AF6mHYwB4AT3/ERMtsa
   ZAuw7Sfx58+V1Z2UItrTV1H7D8RXTKE7MO5plb2796rKXWXq2GTzrnzA/5JXldwL
   FWc4OFsd/AY7vlpxOQ6wr3cCte1GWRAEjFCURZnyHBK7Ejgn8BuFmTfyTXzrWOUP
   bksHRiRd9XJJvxJlU8hYexkCgYBhM9i24THTVVnUtyTn1b+o1lsjnxWAL7c674uO
   gxCGu2w6C8leeiXNzBrZb8Mlk4lOJcQpwtDCNzsSySmy0bWas8ngvRmeam16sAzd
   dX0Gx0HWPSasNrwEddVvMPYqlbNGPv+78quAQ4AW+zqoGzjDm1pjSAJrunJi2yzQ
   G7MNQQKBgCZktECUg2xr8vgVTB586sB7PiHp2j8Wabxh+dMiNUEB7qg4HZdzh8XA
   JXnJnZVQWBL0s10yPg9oITWVBcZ3MqgOqsN1QamN9KjzA46ILtpWptz2q3Nw2Tkl
   m7RBP9R9gM9mnl9/azK7Y5uj11/O3cNJLEIWcraKqydPfvxNyEtP -----END RSA
   PRIVATE KEY-----

   rsa.public: -----BEGIN PUBLIC KEY-----
   MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2LNjBAdNAtZOMdd3hlem
   ZF8a0onOcEo5g1KWnKzryDCfH4LZkXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly
   9ztBXc4obY5wnQpl4nbvOdf6vyLy7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL
   6MDWLU9ZSWlqskzLVPgwqtT80xchU65HipKkr2luSAySZyyNEf58pRea3D3pBkLy
   5hCDhr2+6GF2q9lJ9qMopd2P/ZXxHkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfV
   wrs4495a8OUkOBy7V4YkgKbFYSSkGPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj
   1QIDAQAB -----END PUBLIC KEY-----

   File containing domain, domain.txt:

   $ cat domain.txt

   s=foo-example.com&p=example.com

   $ openssl dgst -sha256 -sign rsa.private -out foo.sign domain.txt

   $ base64 foo.sign TkKgbCV7xXWYES+I5y8KRvgQet7SOLUYTbJtjVyb2/H/
   phI4EcalpxhDfADPgCRwxASztR12BMq0 MLWJZZYxN1zuBE3joFED7EHRoDlFQti/
   GtRFg9lyOSLac58dyty3rdU2oLDSubbk21YYZZV7VsUh OqbGxrhe6LdY0f59aw7cGg2R
   +YIX0dW9z+I3cOcZKtdlfea42AS6sL4vJBy+ytWmfJC62wDL5IT3 HDmWVEmZg7GcSbT0
   62zQBUX0Xo3sDOquXyA2qzat4Gbq3FJeSTFEc3UQipHFBohb0qIkbWv2IeHC
   m2nYjnaCi8P9o3y2nBn1rfzuHB2ctPnnTqK+eg==

   The published record would be: "v=RDBD1;s=2018a;d=example.com;
   h=TkKgbCV7xXWYES+I5y8KRvgQet7SOLUYTbJtjVyb2/H/
   phI4EcalpxhDfADPgCRwxASztR12BMq0 MLWJZZYxN1zuBE3joFED7EHRoDlFQti/
   GtRFg9lyOSLac58dyty3rdU2oLDSubbk21YYZZV7VsUh OqbGxrhe6LdY0f59aw7cGg2R
   +YIX0dW9z+I3cOcZKtdlfea42AS6sL4vJBy+ytWmfJC62wDL5IT3 HDmWVEmZg7GcSbT0
   62zQBUX0Xo3sDOquXyA2qzat4Gbq3FJeSTFEc3UQipHFBohb0qIkbWv2IeHC
   m2nYjnaCi8P9o3y2nBn1rfzuHB2ctPnnTqK+eg=="

   To verify:




Brotman & Farrell        Expires August 29, 2019                [Page 7]


Internet-Draft                    RDBD                     February 2019


   with "foo.base64" containing the above signature:

   $ openssl base64 -d -in foo.base64 -out sign.sha256

   $ openssl dgst -sha256 -verify rsa.public -signature sign.sha256
   domain.txt Verified OK

Authors' Addresses

   Alex Brotman
   Comcast, Inc

   Email: alex_brotman@comcast.com


   Stephen Farrell
   Trinity College Dublin

   Email: stephen.farrell@cs.tcd.ie
































Brotman & Farrell        Expires August 29, 2019                [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/