rdbd-newrrs.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-brotman-rdbd-03">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="RDBD">Related Domains By DNS</title>

<author initials="A." surname="Brotman" fullname="Alex Brotman">
<organization>Comcast, Inc</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>alex_brotman@comcast.com</email>
<uri></uri>
</address>
</author>
<author initials="S." surname="Farrell" fullname="Stephen Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>stephen.farrell@cs.tcd.ie</email>
<uri></uri>
</address>
</author>
<date year="2019" month="September" day="13"/>

<area>Applications</area>
<workgroup></workgroup>
<keyword></keyword>


<abstract>
<t>This document outlines a mechanism by which a DNS domain can
publicly document the existence or absence of a relationship with a different domain, called
&quot;Related Domains By DNS&quot;, or &quot;RDBD&quot;.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>[[Discussion of this draft is taking place on the dbound@ietf.org mailing list.
There's a github repo for this draft at
<eref target="https://github.com/abrotman/related-domains-by-dns"/> -
issues and PRs are welcome there.]]
</t>
<t>Determining relationships between registered domains can be one of the more difficult
investigations on the Internet.  It is typical to see something such as
<spanx style="verb">example.com</spanx> and <spanx style="verb">dept-example.com</spanx> 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
the DNS or WHOIS/RDAP may be sufficient.  However, service providers of various
kinds may err on the side of caution and treat one of the domains as
untrustworthy or abusive because it is not clear that the two domains are in
fact related. This specification provides a way for one domain to
explicitly document a relationship with another, utilizing DNS records.
</t>
<t>Possible use cases include:
</t>
<t>
<list style="symbols">
<t>where a company has websites in different languages, and would like to
correlate their ownership more easily, consider <spanx style="verb">example.de</spanx> and <spanx style="verb">example.ie</spanx>
registered by regional offices of the same company;</t>
<t>following an acquisition, a domain holder might want to indicate that
example.net is now related to example.com in order to make a later migration
easier;</t>
<t>when doing Internet surveys, we should be able to provide more accurate results
if we have information as to which domains are related.</t>
</list>
</t>
<t>Similarly, a domain may wish to declare that no relationship exists with
some other domain, for example &quot;good.example&quot; may want to declare that
it is not associated with &quot;g00d.example&quot; if the latter is currently being
used in some cousin-domain style attack. In such cases, it is more
likely that there can be a larger list of names (compared to the
&quot;positive&quot; use-cases) for which there is a desire to disavow a
relationship.
</t>
<t>It is not a goal of this specification to provide a high-level of
assurance as to whether or not two domains are definitely related, nor to provide
fine-grained detail about the kind of relationship that may
exist between domains.
</t>
<t>Using &quot;Related Domains By DNS&quot;, or &quot;RDBD&quot;, it is possible to
declare that two domains are related, or to disavow such a
relationship.
</t>
<t>We include an optional digital signature mechanism that can somewhat improve the
level of assurance with which an RDBD declaration can be handled.
This mechanism is partly modelled on how DKIM <xref target="RFC6376"/> handles public
keys and signatures - a public key is hosted at the Relating-domain
(e.g., <spanx style="verb">example.com</spanx>) and a reference from the Related-domain
(e.g., <spanx style="verb">dept-example.com</spanx>) contains a signature (verifiable with
the <spanx style="verb">example.com</spanx> public key) over the text representation ('A-label') of
the two domain names (plus a couple of other inputs).
</t>
<t>RDBD is intended to declare or disavow a relationship between registered
domains, not individual hostnames.  That is to say that the
relationship should exist between <spanx style="verb">example.com</spanx> and <spanx style="verb">dept-example.com</spanx>,
not <spanx style="verb">foo.example.com</spanx> and <spanx style="verb">bar.dept-example.com</spanx> (where those latter
two are hosts).
</t>
<t>There already exists Vouch By Reference (VBR) <xref target="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.
</t>
<t>This document describes the various options, how to
create records, and the method of validation, if the option to
use digital signatures is chosen.
</t>

<section anchor="terminology" title="Terminology">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and
&quot;OPTIONAL&quot; in this document are to be interpreted as described in
<xref target="RFC2119"/>.
</t>
<t>The following terms are used throughout this document:
</t>
<t>
<list style="symbols">
<t>Relating-domain: this refers to the domain that is
declarating a relationship exists. (This was called the
&quot;parent/primary&quot; in -00).</t>
<t>Related-domain: This refers to the domain that is
referenced by the Relating-domain, such as <spanx style="verb">dept-example.com</spanx>.
(This was called the &quot;secondary&quot; in -00.)</t>
</list>
</t>
</section>
</section>

<section anchor="new-resource-record-types" title="New Resource Record Types">
<t>We define two new RRTYPES, an optional one for the Relating-domain (RDBDKEY)
to store a public key for when signatures are in use and one for use in
Related-domains (RDBD).
</t>

<section anchor="rdbdkey-resource-record-definition" title="RDBDKEY Resource Record Definition">
<t>The RDBDKEY record is published at the apex of the Relating-domain zone.
</t>
<t>The wire and presentation format of the RDBDKEY
resource record is identical to the DNSKEY record. <xref target="RFC4034"/>
</t>
<t>[[All going well, at some point we'll be able to say...]]
IANA has allocated RR code TBD for the RDBDKEY resource record via Expert
Review.
<vspace/>
[[In the meantime we're experimenting using 0xffa8, which is decimal 65448,
from the experimental RR code range, for the RDBDKEY resource record.]]
</t>
<t>The RDBDKEY RR uses the same registries as DNSKEY for its
fields. (This follows the precedent set for CDNSKEY in <xref target="RFC7344"/>.)
</t>
<t>No special processing is performed by authoritative servers or by
resolvers, when serving or resolving.  For all practical purposes,
RDBDKEY is a regular RR type.
</t>
<t>The flags field of RDBDKEY records MUST be zero. [[Is that correct/ok? I've
no idea really:-)]]
</t>
<t>There can be multiple occurrences of the RDBDKEY resource record in the
same zone
</t>
</section>

<section anchor="rdbd-resource-record-definition" title="RDBD Resource Record Definition">
<t>To declare a relationship exists an RDBD resource record is published at the
apex of the Related-domain zone.
</t>
<t>To disavow a relationship an RDBD resource record is published at the apex of
the Relating-domain zone.
</t>
<t>[[All going well, at some point we'll be able to say...]]
IANA has allocated RR code TBD for the RDBD resource record via Expert
Review.
<vspace/>
[[In the meantime we're experimenting using 0xffa3, which is decimal 65443,
from the experimental RR code range, for the RDBD resource record.]]
</t>
<t>The RDBD RR is class independent.
</t>
<t>The RDBD RR has no special Time to Live (TTL) requirements.
</t>
<t>There can be multiple occurrences of the RDBD resource record in the
same zone.
</t>
<t>The wire format for an RDBD RDATA consists of a two octet rdbd-tag, the
Relating-domain name(s), and the optional signature fields which are: a two-octet
key-tag, a one-octet signature algorithm, and the digital signature bits.
</t>

<figure align="center"><artwork align="center" type="ascii-art">
                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           rdbd-tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                  Related-domain name or URL                   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+|
   |    key-tag                    | sig-alg     |                 /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 /
   /                            signature                          /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t>We define two possible values for the rdbd-tag in this specification,
later specifications can define new rdbd-tag values:
</t>
<t>
<list style="symbols">
<t>0: states that no relationship exists between the domains</t>
<t>1: states that some relationship exists between the domains</t>
</list>
</t>
<t>The Related-domain name field contains either a single domain
name, or an HTTPS URL. In the latter case, successfully de-referencing that
URL results in a JSON object that contains the list of domain
names, such as is shown in the figure below.
</t>

<figure align="center"><artwork align="center" type="ascii-art">

    [ 
        "example.com", 
        "example.net",
        "foo.example"
    ]
    
</artwork></figure>
<t>If an optional signature is included, the sig-alg field MUST contain
the signature algorithm used, with the same values used as would be
used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for
the corresponding public key.
</t>
<t>If the optional signature is omitted, then the presentation form of the
key-tag, sig-alg and signature fields MAY be omitted. If not omitted then the
sig-alg and key-tag fields MUST be zero and the signature field MUST be a an
empty string. [[Is that the right way to have optional fields in RRs? Not
sure.]]
</t>
<t>The input to signing (&quot;to-be-signed&quot; data) is the concatenation of the
following linefeed-separated (where linefeed has the value '0x0a') lines:
</t>

<figure align="center"><artwork align="center" type="ascii-art">
relating=&lt;Relating-domain name&gt;
related=&lt;Related-domain name or URL&gt;
rdbd-tag=&lt;rdbd-tag value&gt;
key-tag=&lt;key-tag&gt;
sig-alg=&lt;sig-alg&gt;

</artwork></figure>
<t>The Relating-domain and Related-domain values MUST be the 'A-label'
representation of these names.
</t>
<t>The trailing &quot;.&quot; representing the DNS root MUST NOT be included in
the to-be-signed data, so a Relating-domain value above might be
&quot;example.com&quot; but &quot;example.com.&quot; MUST NOT be used as input to
signing.
</t>
<t>A linefeed MUST be included after the &quot;sig-alg&quot; value in the
last line.
</t>
<t>[[Presentation syntax and to-be-signed details are very liable to change.]]
</t>
<t>See the examples in the Appendix for further details.
</t>
</section>
</section>

<section anchor="directionality-and-cardinality" title="Directionality and Cardinality">
<t>RDBD relationships are uni-directional. If bi-directional relationships
exist, then both domains can publish RDBD RRs and optionally sign those.
</t>
<t>If one domain has relationships with many others, then the relevant
RDBD RRs (and RDBDKEY RRs) can be published to represent those or
one RDBD RR can contain an HTTPS URL at which one can provide a list of
names.
</t>
</section>

<section anchor="conflicting-tag-values" title="Conflicting Tag Values">
<t>It is possible to define a relationship more than once.  If it an
investigating entity finds that a domain is related to more than once,
and the <spanx style="verb">rdbd-tag</spanx> has a conflicting value, the investigator SHOULD treat
the relationship as unstated.
</t>
</section>

<section anchor="undocumented-tags" title="Undocumented Tags">
<t>If a relationship is found to have an invalid or undocumented <spanx style="verb">rdbd-tag</spanx>,
the investigating party SHOULD treat the relationship as unstated.
</t>
</section>

<section anchor="https-resources" title="HTTPS Resources">
<t>If the RDBD record references an HTTPS URI for inclusion, the URI MUST
be located at the domain stating the relationship using a
&quot;.well-known&quot; [?RFC8615] location.  The base location for the domain
<spanx style="verb">example.com</spanx> asserting relationships might be located within:
</t>
<t><eref target="https://example.com/.well-known/rdbd/"/>
</t>
<t>The domain may wish to use a sub-domain such as <spanx style="verb">reference.example.com</spanx>.
Furthermore, the URI will specify a file within the <spanx style="verb">.well-known</spanx> directory
stated above, but the filename is left to the diescretion of the domain owner.
An example of a full URI might be:
</t>
<t><eref target="https://www.example.com/.well-known/rdbd/affirmative.json"/>
</t>
<t>The document being reference MUST be a well-formed JSON [?RFC8259] document.
If the document does not validate as a JSON document, the contents of the
document SHOULD be ignored.
</t>
<t>There should is no defined maximum size for these documents, but a referring
site should be considerate of the retrieving entity's resources.
</t>

<section anchor="document-retrieval" title="Document Retrieval">
<t>When retrieving the document via HTTPS, the certificate presented MUST
properly validate.  If the certificate fails to validate, the retreiving
entity SHOULD ignore the contents of the file located at that resource.
</t>
<t>A site may employ an HTTP redirection if they choose, and the retreiving
entity should honor that redirect.
</t>
</section>
</section>

<section anchor="timetolive" title="Time-To-Live">
<t>The relationship is deemed to be enforced for the duration of time matching
the TTL value of the RDBD record.
</t>
</section>

<section anchor="usecases-for-signatures" title="Use-cases for Signatures">
<t>[[The signature mechanism is pretty complex, relative to anything
else here, so it might be considered as an at-risk feature.]]
</t>
<t>We see two possibly interesting use-cases for the signature mechanism
defined here. They are not mutually exclusive.
</t>

<section anchor="extending-dnssec" title="Extending DNSSEC">
<t>If the Relating-domain and Related-domain zones are both DNSSEC-signed,
then the signature mechanism defined here adds almost no value and so
is unlikely to be worth deploying. If neither zone is DNSSEC-signed,
then again, there may be less value in deploying RDBD signatures. The
minimal value that remains in either such case, is that if a client
has acquired and cached the RDBDKEY values in some secure manner,
then the RDBD signatures do offer some benefit. However, at this
point it is fairly unklikely that RDBDKEY values will be acquired
and cached via some secure out-of-band mechanisms, so we do not
expect much deployment of RDBD signatures in either the full-DNSSEC
or no-DNSSEC cases.
</t>
<t>However, where the Relating-domain's zone is DNSSEC-signed, but the
Related-domain's zone is not DNSSEC signed, then the RDBD signatures
do provide value, in essence by extending DNSSEC &quot;sideways&quot; to the
Related-domain. Figure 17 below illustrates this situation.
</t>

<figure align="center"><artwork align="center" type="ascii-art">

+-----------------+
| Relating-domain |
| (DNSSEC-signed) |         +---------------------+
| RDBDKEY-1       |&lt;----+   + Related-domain      |
+-----------------+     |   | (NOT DNSSEC-signed) |
                        +---+ RDBD RR with SIG    |
                            +---------------------+

Figure 17: Extending DNSSEC use-case for RDBD signatures

</artwork></figure>
<t>The overall benefit is that the Relating-domain in this case
need not publish new RR values for each Related-domain.
Without the signatures, every new related domain would
require an update to the zone file for the Relating-domain.
With signatures, the relevant private key holder can
publish a new RR value in each Related-domain without
there being any need to update the Relating-domain.
</t>
</section>

<section anchor="manytoone-usecase" title="Many-to-one Use-Case">
<t>Providing reasonable confidence that a relationship
exists without use of the signature mechanism likely
requires both the Relating-domain zone and the
Related-domain zone to be updated.
</t>
<t>If a relationship exists between one Relating-domain
and many Related-domains and the signature scheme is
not used, then making the many required changes to the
Relating-domain zone could be onerous. Instead, the
signature mechanism allows one to publish a stable
value (the RDBDKEY) once in the Relating-domain.
Each Related-domain can then also publish a stable
value (the RDBD RR with a signature) where the
signature provides confirmation that both domains
are involved in the relationship.
</t>
<t>This scenario makes sense if the relationship (represented
by the rdbd-tag) between
the domains is inherently directional, for example, if
the relationship between the Related-domains and
Relating-domain is akin to a membership relationship.
</t>
<t>If the relationship in question is more &quot;balanced&quot; then
by definition we are in a many-to-one situation, but
rather a many-to-many situation where the signature
mechanism again is no real help.
</t>
</section>
</section>

<section anchor="required-signature-algorithms" title="Required Signature Algorithms">
<t>Consumers of RDBD RRs MAY support signature verification. They
MUST be able to parse/process unsigned or signed RDBD RRs even if they
cannot cryptographically verify signatures.
</t>
<t>Implementations producing RDBD RRs SHOULD support optional signing of those
and production of RDBDKEY RRs.
</t>
<t>Implementations of this specification that support signing or verifying
signatures MUST support use of RSA with
SHA256 (sig-alg==8) with at least 2048 bit RSA keys. <xref target="RFC5702"/>
</t>
<t>RSA keys MUST use a 2048 bit or longer modulus.
</t>
<t>Implementations of this specification that support signing or verifying
signatures SHOULD support use of Ed25519
(sig-alg==15). <xref target="RFC8080"/><xref target="RFC8032"/>
</t>
</section>

<section anchor="validation" title="Validation">
<t>A validated signature is solely meant to be additional evidence that the
relevant domains are related, or that one disavows such a relationship.  The
existence or disavowal of a relationship does not by itself mean that data or
services from any domain should be considered as more or less trustworthy.
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">

<section anchor="efficiacy-of-signatures" title="Efficiacy of signatures">
<t>The optional signature mechanism defined here offers no protection against an
active attack if both the RDBD and RDBDKEY values are accessed via an untrusted
path.
</t>
<t>If the RDBDKEY value has been cached, or is otherwise known via some
sufficiently secure mechanism, then the RDBD signature does confirm that the
holder of the private key (presumably the Relating-domain) considered that the
relationship, or lack thereof, with a Related-domain was real at some point
in time.
</t>
</section>

<section anchor="dnssec" title="DNSSEC">
<t>RDBD does not require DNSSEC. Without DNSSEC it is 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.  An attacker could also replay an old RDBD
value that is actually no longer published in the DNS by the Related-domain.
</t>
<t>Deploying signed records with DNSSEC should allow for detection
of these kinds of attack.
</t>
<t>If the Relating-domain has DNSSEC deployed, but the Related-domain
does not, then the optional signature can (in a sense) extend the
DNSSEC chain to cover the RDBD RR in the Related-domain's zone.
</t>
<t>If both domains have DNSSEC deployed, and if the Relating-domain public key has
been cached, then the the signature mechanism provides additional protection
against active attacks involving a parent of one of the domains.  Such attacks
may in any case be less likely and detectable in many scenarios as they would
be generic attacks against DNSSEC-signing (e.g. if a regisgtry injected a bogus
DS for a Relating-domain into the registry's signed zone). If the
public key from the relevant RDNDKEY RRs is read from the DNS at the
same time as a related RDBD RR, then the signature mechanism provided here
may provide litle additional value over and above DNSSEC.
</t>
</section>

<section anchor="lookup-loops" title="Lookup Loops">
<t>It's conceivable that an attacker could create a loop of relationships, such as
a.com-&gt;b.com-&gt;c.com-&gt;a.com or similar.  This could cause a resource issue for
any automated system.  A system SHOULD only perform three lookups from the
first domain (a.com-&gt;b.com-&gt;c.com-&gt;d.com).  The Related-domain and Relating-domains
SHOULD attempt to keep links direct and so that only the fewest number of
lookups are needed, but it is understood this may not always be possible.
</t>
</section>
</section>

<section anchor="iana-considerations" title="IANA Considerations">
<t>This document introduces two new DNS RR types, RDBD and RDBDKEY.  [[Codepoints
for those are not yet allocated by IANA, nor have codepoints been requested
so far.]]
</t>
<t>[[New rdbd-tag value handling wll need to be defined if we keep
that field. Maybe something
like: 0-255: RFC required; 256-1023: reserved; 1024-2047: Private
use; 2048-65535: FCFS.]]
</t>
</section>

<section anchor="acknowledgements" title="Acknowledgements">
<t>Thanks to all who commented on this on the dbound and other lists,
in particular to the following who provided comments that caused us
to change the draft:
Bob Harold,
John Levine,
Pete Resnick,
Andrew Sullivan,
Tim Wisinski,
Suzanne Woolf,
Joe St. Sauver,
and
Paul Wouters.
(We're not implying any of these fine folks actually like this
draft btw, but we did change it because of their comments:-)
Apologies to anyone we missed, just let us know and we'll add
your name here.
</t>
</section>

</middle>
<back>
<references title="Informative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5518.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5702.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7344.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8080.xml"?>
</references>

<section anchor="implementation-and-deployment-status" title="Implementation (and Deployment:-) Status">
<t>[[Note to RFC-editor: according to RFC 7942, sections such as
this one ought not be part of the final RFC. I still dislike
that idea, but whatever;-)]]
</t>
<t>We are not aware of any independent implementations so far.  One of the authors
has a github repo at <eref target="https://github.com/sftcd/rdbd-deebeedeerrr"/> with scripts
that allow one to produce zone file fragments and signatures for a set of
domains. See the README there for details.
</t>
<t>In terms of deployments, we used the above for a &quot;toy&quot; deployment in the
tolerantnetworks.ie domain and other related domains that one cen determine by
following the relevant trail:-)
</t>
</section>

<section anchor="examples" title="Examples">
<t>This appendix provides examples of RDBD-related values.
The following names and other values are used in these examples.
</t>
<t>
<list style="symbols">
<t>Relating domain: my.example</t>
<t>Related domain: my-way.example</t>
<t>Unrelated domain: my-bad.example</t>
<t>URL for other related domains: <eref target="https://example.com/related-names"/></t>
<t>URL for other unrelaed domains: <eref target="https://example.com/unrelateds"/></t>
</list>
</t>
<t>The github repo
<eref target="https://github.com/abrotman/related-domains-by-dns"/>
has a script in sample/mk_samples.sh that generated this appendix.
</t>

<section anchor="unsigned-examples" title="Unsigned Examples">

<figure align="center"><artwork align="center" type="ascii-art">

;ZONE FILE FRAGMENT STARTS
; assertion that my-way.example claims to be related 
; to my.example
my-way.example. 3600 IN RDBD 1 my.example.

; assertion that my-way.example claims not to be 
; related to my-bad.example
my-way.example. 3600 IN RDBD 0 my-bad.example.

; assertion that my-way.example claims to be related 
; to whatever is at https://example.com/related-names
my-way.example. 3600 IN RDBD 1 https://example.com/related-names

; assertion that my-way.example claims not to be 
; related to whatever is at https://example.com/related-names
my-way.example. 3600 IN RDBD 0 https://example.com/unrelateds

;ZONE FILE FRAGMENT ENDS

</artwork></figure>
</section>

<section anchor="rsasigned-example" title="RSA-signed Example">

<figure align="center"><artwork align="center" type="ascii-art">

# BASH SNIPPET STARTS
# HOWTO generate RSA key pair
$ openssl genrsa -out rsa.private 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....................+++++
.....................+++++
e is 65537 (0x010001)
writing RSA key
$ openssl rsa -in rsa.private -out rsa.public -pubout \
     -outform PEM 
$ cat rsa.private
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA8qpGa2i6O76MdGiFVYGgd6UDYfUNl4qHpXfzmrqawUqb8JHM
5m8hjLTbKDGRpZJA5m9sQlaM41hQxpAPuW3mJXYvVOiqxtRCBlVTvUCR+Gkah7LU
FT54U8PT+ciF2or2ArL7O1LIT1PnEL0AZsbM6FwYLsRE8RX89PqeL9N/U4xJ7jQq
SRK88bnRRFs+W7F+iQuA5erHfIZHftq+yzRG8rtgTN7HvTOewkDa2XS2Tn/z0tRV
wNUX4Mi4e/DaEZU0u3kn7HqL0hyBXz/EEHUq9+57BURUT/ZQ41ORGgJ/4+tv2Gp8
mp1ydOJaAhzgqky2zGBL1RS+mBFCio9dXBIJywIDAQABAoIBAQDwE7ITtcr6LKy8
xmOTkul1NVZBZbYKxU0qUaA65n8Q2IWq3jR/jlb85DkmbNQRoL6AvJ+4ifRdQBS6
PfCwnZ/iVCjDsmSyzXB835I3XFiOET3kHvJgCiv1g3qGVvLGolB9nyGbMW1nvjSO
hM6O4AP9po9uRVOHyR84J3K1EmOX/PgmITPel61CEe+IdYwX3K3w1Mmm9C3ZSitx
rx8gpWHknpAG9Z+DA+f406TFTFtuTQe6xCDjKl0/uUGsT62UQqEiw00wekm8e+2b
rDdtqu61Lqq1aakhtGlozXIT7ED+oobp6cAnM1QbV09z7zZevXl95yrXt9xZ3odS
HNcHnMCRAoGBAP6N00vMmplk76OOJ738Twf6fsaL+zkwNmL74Rv85LJn96p6xQUm
wJdMsa7HoD7LwuxhJkhDbdTiq+oV+Mc4J+FAe5xRK5vD7wVmPNWtUcvwdTZXnpNr
6fU28PqL76feU22G/V2mthgKOXPvYehcteAJAEGbLwQoo1Q7qZa7Q9i/AoGBAPQL
KSqcOzGHJ57iYN+HbN0cqXpBburA7dZstl6WiwQO0U4+KsJ3eyyuUE0Mz6epXeQD
Ry1W8yoH9ypfLDEP3YwP3wp7dqISyGAzsRospGyGJ0tHkQ3orW+/6PgSl9W2aJV2
LqyfOPutrjfIRUkgALMq8cTRxR1xpx0HpVfOMCX1AoGAJi9SPfGgU1hf1lIRxh8e
H91EvTXsZqTD089i8lbaW6Ta8xjdiytIAqo/kS9i62iXgewE2Rw8Uo36KfBH1GKp
INISeN14RDJ9HXs7rvYD6irU+mTkZcrvWph2R69MMQtZynlQcob6k9qcybZkIn4d
zlCrWCwWPnJ2JcGZbAIFaHMCgYBXIdD95LABu/a6dKsPxANrYrtj6g7XBDEmuMPY
O7nApiW24N1Vd2FkD4yeJe/SNddO/JiiKIRDQnrOBxL5JWf9hQEmdfRiY4BlUK9v
3/aIxNEswI2awLODzao5QDIz3J+0lXCOs36d5WHpiriqJiH51mBh3F+bZqO66qrv
EbABLQKBgDUhcsEyIMI6oygKO/L+iVOZM+ao+64TtKxqUmgHU+gBgvdkY8h9GvxY
kL7L1hBOB9bAyP8ObU18R5CMbQgO7PITACRoU+uYIiQ67UREDKjBRtoDcgK0JrRX
kqy4v6LuuFCpS5OJKQL6rKfk2XNSjDD1ZwLuBZjHQDdc/gnn7XRx
-----END RSA PRIVATE KEY-----
$ cat rsa.public
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8qpGa2i6O76MdGiFVYGg
d6UDYfUNl4qHpXfzmrqawUqb8JHM5m8hjLTbKDGRpZJA5m9sQlaM41hQxpAPuW3m
JXYvVOiqxtRCBlVTvUCR+Gkah7LUFT54U8PT+ciF2or2ArL7O1LIT1PnEL0AZsbM
6FwYLsRE8RX89PqeL9N/U4xJ7jQqSRK88bnRRFs+W7F+iQuA5erHfIZHftq+yzRG
8rtgTN7HvTOewkDa2XS2Tn/z0tRVwNUX4Mi4e/DaEZU0u3kn7HqL0hyBXz/EEHUq
9+57BURUT/ZQ41ORGgJ/4+tv2Gp8mp1ydOJaAhzgqky2zGBL1RS+mBFCio9dXBIJ
ywIDAQAB
-----END PUBLIC KEY-----
# To-be-signed data for RSA
$ cat  to-be-signed-8.txt
relating=my.example
related=my-way.example
rdbd-tag=1
key-tag=38501
sig-alg=8
# Sign that
$ openssl dgst -sha256 -sign rsa.private -out rsa.sig \
        to-be-signed-8.txt
# Hexdump of signature
$ hexdump rsa.sig
0000000 8664 bd57 8cbf a8e1 9182 1b5f a4fc 5eb9
0000010 49b4 fe21 f1c7 8097 ed90 44a5 bcb1 543c
0000020 f784 c190 e1d9 2f2b 18ca d3c2 640f 3823
0000030 7f8a e446 d0eb bd14 6077 0597 6015 a82b
0000040 42d7 8677 b1a3 37fa a1e8 8109 07ec ff62
0000050 16b8 3895 66de d992 dc4d ed99 9ec3 0a62
0000060 6a07 3baa 45f2 d528 1e83 a147 60ce 9b25
0000070 a967 4ba0 3fb5 98db 5ff3 b070 058b 4d8f
0000080 f198 6c1f e6b6 7a6c 1e8c ad42 237f 5440
0000090 7856 caac f96c f87d e79c 4dc5 b833 bc03
00000a0 c52e 5603 46a7 59b5 9fe3 fccd 04ee e908
00000b0 71e7 21f8 47ad fea8 40bf 14a5 9e6b b3d4
00000c0 c61a 5b96 c559 3491 4dfa 91a0 4c0b f3ff
00000d0 e460 484c 7e49 5368 85e3 16be fe6b 809a
00000e0 117d c2cb be19 c5ba 7594 2f60 16ad 1132
00000f0 f978 6ca1 5448 180f 8ca7 e73d 1137 7064
0000100
# BASH SNIPPET ENDS

; ZONE FILE FRAGMENT STARTS
; The RDBDKEY RR for my.example is...
my.example. 3600 IN RDBDKEY 0 3 8 (
            LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C
            Z2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUE4
            cXBHYTJpNk83Nk1kR2lGVllHZwpkNlVEWWZVTmw0cUhwWGZ6
            bXJxYXdVcWI4SkhNNW04aGpMVGJLREdScFpKQTVtOXNRbGFN
            NDFoUXhwQVB1VzNtCkpYWXZWT2lxeHRSQ0JsVlR2VUNSK0dr
            YWg3TFVGVDU0VThQVCtjaUYyb3IyQXJMN08xTElUMVBuRUww
            QVpzYk0KNkZ3WUxzUkU4Ulg4OVBxZUw5Ti9VNHhKN2pRcVNS
            Szg4Ym5SUkZzK1c3RitpUXVBNWVySGZJWkhmdHEreXpSRwo4
            cnRnVE43SHZUT2V3a0RhMlhTMlRuL3owdFJWd05VWDRNaTRl
            L0RhRVpVMHUza243SHFMMGh5Qlh6L0VFSFVxCjkrNTdCVVJV
            VC9aUTQxT1JHZ0ovNCt0djJHcDhtcDF5ZE9KYUFoemdxa3ky
            ekdCTDFSUyttQkZDaW85ZFhCSUoKeXdJREFRQUIKLS0tLS1F
            TkQgUFVCTElDIEtFWS0tLS0tCg== )
; The RDBD RR to be published by my-way.example is...
my-way.example. 3600 IN RDBD 1 my.example 38501 8 (
            ZIZXvb+M4aiCkV8b/KS5XrRJIf7H8ZeAkO2lRLG8PFSE95DB
            2eErL8oYwtMPZCM4in9G5OvQFL13YJcFFWArqNdCd4ajsfo3
            6KEJgewHYv+4FpU43maS2U3cme3DnmIKB2qqO/JFKNWDHkeh
            zmAlm2epoEu1P9uY819wsIsFj02Y8R9stuZseoweQq1/I0BU
            Vnisymz5ffic58VNM7gDvC7FA1anRrVZ45/N/O4ECOnncfgh
            rUeo/r9ApRRrntSzGsaWW1nFkTT6TaCRC0z/82DkTEhJfmhT
            44W+Fmv+moB9EcvCGb66xZR1YC+tFjIRePmhbEhUDxinjD3n
            NxFkcA== )
; ZONE FILE FRAGMENT ENDS

</artwork></figure>
</section>

<section anchor="ed25519signed-example" title="Ed25519-signed Example">

<figure align="center"><artwork align="center" type="ascii-art">
# BASH SNIPPET STARTS
# HOWTO generate an Ed25519 key pair...
$ ./ed25519-signer.py -s rdbd-example0001rdbd-example0002 \
   -r my.example -d my-way.example
private:b'726462642d6578616d706c6530303031726462642d6578616d
706c6530303032'
public:b'353fc31e1168c91f0af65d6c26fd441fb7df9671a23a746bb3e
c86be8d35b648'
b64pubkey: NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRrs+yGvo01tkg=
keyid: 35988
to-be-signed:|relating=my.example
related=my-way.example
rdbd-tag=1
key-tag=35988
sig-alg=15
|
sig:b'64bc444ce759fb9435fe9c1875eb241c4ec6d0995cd8138a372782
32fc8e79f53cb8f88059f6040054c61be8cfd73fd44521f73994628fc7c3
0135fa929ab00f'
# hex dump of Ed25519 private
$ hexdump ed25519.priv
0000000 6472 6462 652d 6178 706d 656c 3030 3130
0000010 6472 6462 652d 6178 706d 656c 3030 3230
0000020
# hex dump of Ed25519 public
$ hexdump ed25519.pub
0000000 3f35 1ec3 6811 1fc9 f60a 6c5d fd26 1f44
0000010 dfb7 7196 3aa2 6b74 ecb3 be86 358d 48b6
0000020
# hex dump of Ed25519 signature
$ hexdump ed25519.sig
0000000 bc64 4c44 59e7 94fb fe35 189c eb75 1c24
0000010 c64e 99d0 d85c 8a13 2737 3282 8efc f579
0000020 b83c 80f8 f659 0004 c654 e81b d7cf d43f
0000030 2145 39f7 6294 c78f 01c3 fa35 9a92 0fb0
0000040
# BASH SNIPPET ENDS

; ZONE FILE FRAGMENT STARTS
; The RDBDKEY RR for my.example is...
my.example. 3600 IN RDBDKEY 0 3 15 (
            NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRrs+yGvo01tkg= ) 
; The RDBD RR to be published by my-way.example is...
my-way.example. 3600 IN RDBD 1 my.example 35988 15 (
            ZLxETOdZ+5Q1/pwYdeskHE7G0Jlc2BOKNyeCMvyOefU8uPiA
            WfYEAFTGG+jP1z/URSH3OZRij8fDATX6kpqwDw== ) 
; ZONE FILE FRAGMENT ENDS

</artwork></figure>
</section>
</section>

<section anchor="ed25519-signing-code" title="Ed25519 Signing Code">
<t>Since OpenSSL does not yet support Ed25519 signing via its command
line tool, we generate our example using the python script below,
which is called as &quot;ed25519-signer.py&quot; above.
This uses the python library from Appendix A of <xref target="RFC8032"/>.
</t>

<figure align="center"><artwork align="center" type="ascii-art">

#!/usr/bin/env python3
# CODE_BEGINS
import argparse, sys, binascii
from eddsa2 import Ed25519

# from https://gist.github.com/wido/4c6288b2f5ba6d16fce37dca3fc2cb4a
def calc_keyid(flags, protocol, algorithm, dnskey):
    st=struct.pack('!HBB', int(flags), int(protocol), int(algorithm))
    st+=base64.b64decode(dnskey)
    cnt = 0
    for idx in range(len(st)):
        s = struct.unpack('B', st[idx:idx+1])[0]
        if (idx % 2) == 0:
            cnt += s &lt;&lt; 8
        else:
            cnt += s
    return ((cnt &amp; 0xFFFF) + (cnt &gt;&gt; 16)) &amp; 0xFFFF

def main():
    parser=argparse.ArgumentParser(description='Ed25519 signing')
    parser.add_argument('-s','--secret',
                        dest='secret', help='secret key')
    parser.add_argument('-r','--relating',
                        dest='relating', help='relating domain')
    parser.add_argument('-d','--related',
                        dest='related', help='related domain')
    parser.add_argument('-n','--negative',
                        dest='negative', help='negative assertion')
    args=parser.parse_args()

    if args.secret is None:
        print("You do need a secret... - exiting")
        sys.exit(1)
    # secret has to be 32 octets funnily enuugh:-)
    # e.g. secret="rdbd-example0001rdbd-example0002".encode('utf-8')
    if len(args.secret)!=32:
        print("Secret has to be 32 octets... - exiting")
        sys.exit(1)
    if args.relating is None:
        print("You do need a relating domain... - exiting")
        sys.exit(1)
    if args.related is None:
        print("You do need a related domain... - exiting")
        sys.exit(1)
    secret=args.secret.encode('utf-8')
    privkey,pubkey = Ed25519.keygen(secret)
    print("private:"+ str(binascii.hexlify(privkey)))
    print("public:"+ str(binascii.hexlify(pubkey)))

    b64pubkey=binascii.b2a_base64(pubkey).rstrip().decode("utf-8")
    print("b64pubkey: " + b64pubkey)

    keyid=calc_keyid("0","3","15",b64pubkey)
    print("keyid: " + str(keyid))

    rdbdtag="1"
    if args.negative:
        rdbdtag="0"

    tbs="relating="+args.relating+"\nrelated="+\
          args.related+"\nrdbd-tag="+rdbdtag+\
          "\nkey-tag="+str(keyid)+"\nsig-alg=15\n"
    print("to-be-signed:|" + str(tbs)+"|")

    with open("ed25519.priv", "wb") as privf:
        privf.write(privkey)
    with open("ed25519.pub","wb") as pubf:
        pubf.write(pubkey)
    with open("to-be-signed-15.txt","wb") as tbsf:
        tbsf.write(tbs.encode('utf-8'))

    msg=tbs.encode('utf-8')
    signature = Ed25519.sign(privkey, pubkey, msg)
    print("sig:"+ str(binascii.hexlify(signature)))
    with open("ed25519.sig", "wb") as sigf:
        sigf.write(signature)
    return

if __name__ == "__main__":
    main()

# CODE_ENDS
</artwork></figure>
</section>

<section anchor="changes-and-open-issues" title="Changes and Open Issues">
<t>[[RFC editor: please delete this appendix ]]
</t>

<section anchor="changes-from-02-to-03" title="Changes from -02 to -03">
<t>
<list style="symbols">
<t>Incorporated feedback/comments from IETF-105</t>
<t>Adopted some experimental RRCODE value</t>
</list>
</t>
</section>

<section anchor="changes-from-01-to-02" title="Changes from -01 to -02">
<t>
<list style="symbols">
<t>Added negative assertions based on IETF104 feedback</t>
<t>Added URL option based on IETF104 feedback</t>
<t>Made sample generation script</t>
<t>Typo fixes etc.</t>
</list>
</t>
</section>

<section anchor="changes-from-00-to-01" title="Changes from -00 to -01">
<t>
<list style="symbols">
<t>Changed from primary/secondary to relating/related (better suggestions
are still welcome)</t>
<t>Moved away from abuse of TXT RRs</t>
<t>We now specify optional DNSSEC-like signatures (we'd be fine with moving
back to a more DKIM-like mechanism, but wanted to see how this looked)</t>
<t>Added Ed25519 option</t>
<t>Re-worked and extended examples</t>
</list>
</t>
</section>

<section anchor="open-issues" title="Open Issues">
<t>Current open github issues include:
</t>
<t>
<list style="symbols">
<t>#5: specify input for signing more precisely - e.g. is there a CR or NULL or not</t>
<t>#6: what, if anything, does rdbd for example.com mean for foo.example.com?</t>
</list>
</t>
<t>These can be seen at: <eref target="https://github.com/abrotman/related-domains-by-dns/issues"/>
</t>
</section>
</section>

</back>
</rfc>