idnits 2.17.1 draft-brotman-rdbd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2019) is 1878 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Brotman 3 Internet-Draft Comcast, Inc 4 Intended status: Standards Track S. Farrell 5 Expires: September 7, 2019 Trinity College Dublin 6 March 6, 2019 8 Related Domains By DNS 9 draft-brotman-rdbd-01 11 Abstract 13 This document outlines a mechanism by which a registered domain can 14 publicly document a relationship with a different registered domain, 15 called "Related Domains By DNS", or "RDBD". 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 7, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. New Resource Record Types . . . . . . . . . . . . . . . . . . 4 54 2.1. RDBDKEY Resource Record Definition . . . . . . . . . . . 4 55 2.2. RDBD Resource Record Definition . . . . . . . . . . . . . 5 56 3. Directionality and Cardinality . . . . . . . . . . . . . . . 6 57 4. Required Signature Algorithms . . . . . . . . . . . . . . . . 6 58 5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6.1. Efficiacy of signatures . . . . . . . . . . . . . . . . . 7 61 6.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.3. Lookup Loops . . . . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Informative References . . . . . . . . . . . . . . . . . . . 8 66 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 67 A.1. Sample Unsigned RDBD RR . . . . . . . . . . . . . . . . . 9 68 A.2. Sample RSA Signature . . . . . . . . . . . . . . . . . . 10 69 A.3. Sample Ed25519 Signature . . . . . . . . . . . . . . . . 13 70 Appendix B. Changes and Open Issues . . . . . . . . . . . . . . 15 71 B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 72 B.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 [[Discussion of this draft is taking place on the dbound@ietf.org 78 mailing list. There's a github repo for this draft at 79 - issues and PRs 80 are welcome there.]] 82 Determining relationships between registered domains can be one of 83 the more difficult investigations on the Internet. It is typical to 84 see something such as "example.com" and "dept-example.com" and be 85 unsure if there is an actual relationship between those two domains, 86 or if one might be an attacker attempting to impersonate the other. 87 In some cases, anecdotal evidence from the DNS or WHOIS/RDAP may be 88 sufficient. However, service providers of various kinds may err on 89 the side of caution and treat one of the domains as untrustworthy or 90 abusive because it is not clear that the two domains are in fact 91 related. This specification provides a way for one domain to 92 explicitly document a relationship with another, utilizing DNS 93 records. 95 Possible use cases include: 97 o where a company has websites in different languages, and would 98 like to correlate their ownership more easily, consider 99 "example.de" and "example.ie" registered by regional offices of 100 the same company; 102 o following an acquisition, a domain holder might want to indicate 103 that example.net is now related to example.com in order to make a 104 later migration easier; 106 o when doing Internet surveys, we should be able to provide more 107 accurate results if we have information as to which domains are 108 related. 110 It is not a goal of this specification to provide a high-level of 111 assurance that two domains are definitely related, nor to provide 112 fine-grained detail about the kind of relationship that may exist 113 between domains. 115 Using "Related Domains By DNS", or "RDBD", it is possible to declare 116 that two domains are related. 118 We include an optional digital signature mechanism that can somewhat 119 improve the level of assurance with which an RDBD declaration can be 120 handled. This mechanism is partly modelled on how DKIM [RFC6376] 121 handles public keys and signatures - a public key is hosted at the 122 relating-domain (e.g., "example.com") and a reference from the 123 related-domain (e.g., "dept-example.com") contains a signature 124 (verifiable with the "example.com" public key) over the text 125 representation ('A-label') of the two domain names (plus a couple of 126 other inputs). 128 RDBD is intended to demonstrate a relationship between registered 129 domains, not individual hostnames. That is to say that the 130 relationship should exist between "example.com" and "dept- 131 example.com", not "foo.example.com" and "bar.dept-example.com" (where 132 those latter two are hosts). 134 There already exists Vouch By Reference (VBR) [RFC5518], however this 135 only applies to email. RDBD could be a more general purpose solution 136 that could be applied to other use cases, as well as for SMTP 137 transactions. 139 This document describes the various options, how to create records, 140 and the method of validation, if the option to use digital signatures 141 is chosen. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119]. 150 The following terms are used throughout this document: 152 o Relating-domain: this refers to the domain that is declarating a 153 relationship exists. (This was called the "parent/primary" in 154 -00). 156 o Related-domain: This refers to the domain that is referenced by 157 the relating-domain, such as "dept-example.com". (This was called 158 the "secondary" in -00.) 160 2. New Resource Record Types 162 We define two new RRTYPES, an optional one for the relating-domain 163 (RDBDKEY) to store a public key for when signatures are in use and 164 one for use in related-domains (RDBD). 166 2.1. RDBDKEY Resource Record Definition 168 The RDBDKEY record is published at the apex of the relating-domain 169 zone. 171 The wire and presentation format of the RDBDKEY resource record is 172 identical to the DNSKEY record. [RFC4034] 174 [[All going well, at some point we'll be able to say...]] IANA has 175 allocated RR code TBD for the RDBDKEY resource record via Expert 176 Review. 178 The RDBDKEY RR uses the same registries as DNSKEY for its fields. 179 (This follows the precedent set for CDNSKEY in [RFC7344].) 181 No special processing is performed by authoritative servers or by 182 resolvers, when serving or resolving. For all practical purposes, 183 RDBDKEY is a regular RR type. 185 The flags field of RDBDKEY records MUST be zero. [[Is that correct/ 186 ok? I've no idea really:-)]] 188 2.2. RDBD Resource Record Definition 190 The RDBD resource record is published at the apex of the related- 191 domain zone. 193 [[All going well, at some point we'll be able to say...]] IANA has 194 allocated RR code TBD for the RDBD resource record via Expert Review. 196 The RDBD RR is class independent. 198 The RDBD RR has no special Time to Live (TTL) requirements. 200 The wire format for an RDBD RDATA consists of a two octet rdbd-tag, 201 the relating-domain name, and the optional signature fields which 202 are: a two-octet key-tag, a one-octet signature algorithm, and the 203 digital signature bits. 205 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | rdbd-tag | / 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 210 / relating-domain name / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+| 212 | key-tag | sig-alg | / 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 214 / signature / 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The rdbd-tag field MUST contain the value zero. Later specifications 218 can define new rdbd-tag values. 220 If an optional signture is included, the sig-alg field MUST contain 221 the signature algorithm used, with the same values used as would be 222 used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for 223 the corresponding public key. 225 If the optional signature is omitted, then the presentation form of 226 the key-tag, sig-alg and signature fields MAY be omitted. If not 227 omitted then the sig-alg and key-tag fields MUST be zero and the 228 signature field MUST be a an empty string. [[Is that the right way 229 to have optional fields in RRs? Not sure.]] 231 The input to signing ("to-be-signed" data) is the concatenation of 232 the following linefeed-separated (where linefeed has the value 233 '0x0a') lines: 235 relating= 236 related= 237 rdbd-tag= 238 key-tag= 239 sig-alg= 241 The relating-domain and related-domain values MUST be the 'A-label' 242 representation of these names. 244 The trailing "." representing the DNS root MUST NOT be included in 245 the to-be-signed data, so a relating-domain value above might be 246 "example.com" but "example.com." MUST NOT be used as input to 247 signing. 249 A linefeed MUST be included after the "sig-alg" value in the last 250 line. 252 [[Presentation syntax and to-be-signed details are very liable to 253 change.]] 255 See the examples in the Appendix for further details. 257 3. Directionality and Cardinality 259 RDBD relationships are uni-directional. If bi-directional 260 relationships exist, then both domains can publish RDBD RRs and 261 optionally sign those. 263 If one domain has relationships with many others, then the relevant 264 RDBD RRs (and RDBDKEY RRs) can be published to represent those. 266 4. Required Signature Algorithms 268 Consumers of RDBD RRs MAY support signature verification. They MUST 269 be able to parse/process unsigned or signed RDBD RRs even if they 270 cannot cryptographically verify signatures. 272 Implementations producing RDBD RRs SHOULD support optional signing of 273 those and production of RDBDKEY RRs. 275 Implementations of this specification that support signing or 276 verifying signatures MUST support use of RSA with SHA256 (sig-alg==8) 277 with at least 2048 bit RSA keys. [RFC5702] 279 RSA keys SHOULD use a 2048 bit or longer modulus. 281 Implementations of this specification that support signing or 282 verifying signatures SHOULD support use of Ed25519 (sig-alg==15). 283 [RFC8080][RFC8032] 285 5. Validation 287 A validated signature is solely meant to be additional evidence that 288 the two domains are related. The existence of this relationship is 289 not meant to state that the data from either domain should be 290 considered as more trustworthy. 292 6. Security Considerations 294 6.1. Efficiacy of signatures 296 The optional signature mechanism defined here offers no protection 297 against an active attack if both the RDBD and RDBDKEY values are 298 accessed via an untrusted path. 300 If the RDBDKEY value has been cached, or is otherwise known via some 301 sufficiently secure mechanism, then the RDBD signature does confirm 302 that the holder of the private key (presumably the relating-domain) 303 considered that the relationship with the related-domain was real at 304 some point in time. 306 6.2. DNSSEC 308 RDBD does not require DNSSEC. Without DNSSEC it is possible for an 309 attacker to falsify DNS query responses for someone investigating a 310 relationship. Conversely, an attacker could delete the response that 311 would normally demonstrate the relationship, causing the 312 investigating party to believe there is no link between the two 313 domains. An attacker could also replay an old RDBD value that is 314 actually no longer published in the DNS by the related-domain. 316 Deploying signed records with DNSSEC should allow for detection of 317 these kinds of attack. 319 If the relating-domain has DNSSEC deployed, but the related-domain 320 does not, then the optional signature can (in a sense) extend the 321 DNSSEC chain to cover the RDBD RR in the related-domain's zone. 323 If both domains have DNSSEC deployed, and if the relating-domain 324 public key has been cached, then the the signature mechanism provides 325 additional protection against active attacks involving a parent of 326 one of the domains. Such attacks may in any case be less likely and 327 detectable in many scenarios as they would be generic attacks against 328 DNSSEC-signing (e.g. if a regisgtry injected a bogus DS for a 329 relating-domain into the registry's signed zone). If the public key 330 from the relevant RDNDKEY RRs is read from the DNS at the same time 331 as a related RDBD RR, then the signature mechanism provided here may 332 provide litle additional value over and above DNSSEC. 334 6.3. Lookup Loops 336 It's conceivable that an attacker could create a loop of 337 relationships, such as a.com->b.com->c.com->a.com or similar. This 338 could cause a resource issue for any automated system. A system 339 SHOULD only perform three lookups from the first domain 340 (a.com->b.com->c.com->d.com). The related and relating-domains 341 SHOULD attempt to keep links direct and so that only the fewest 342 number of lookups are needed, but it is understood this may not 343 always be possible. 345 7. IANA Considerations 347 This document introduces two new DNS RR types, RDBD and RDBDKEY. 348 [[Codepoints for those are not yet allocated by IANA, nor have 349 codepoints been requested so far.]] 351 [[New rdbd-tag value handling wll need to be defined if we keep that 352 field. Maybe something like: 0-255: RFC required; 256-1023: 353 reserved; 1024-2047: Private use; 2048-65535: FCFS.]] 355 8. Acknowledgements 357 Thanks to all who commented on this on the dbound and other lists, in 358 particular to the following who provided comments that caused us to 359 change the draft: Bob Harold, John Levine, Andrew Sullivan, Suzanne 360 Woolf, and Paul Wouters. (We're not implying any of these fine folks 361 actually like this draft btw, but we did change it because of their 362 comments:-) Apologies to anyone we missed, just let us know and we'll 363 add your name here. 365 9. Informative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 373 Rose, "Resource Records for the DNS Security Extensions", 374 RFC 4034, DOI 10.17487/RFC4034, March 2005, 375 . 377 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 378 Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, 379 . 381 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 382 and RRSIG Resource Records for DNSSEC", RFC 5702, 383 DOI 10.17487/RFC5702, October 2009, 384 . 386 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 387 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 388 RFC 6376, DOI 10.17487/RFC6376, September 2011, 389 . 391 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 392 DNSSEC Delegation Trust Maintenance", RFC 7344, 393 DOI 10.17487/RFC7344, September 2014, 394 . 396 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 397 Signature Algorithm (EdDSA)", RFC 8032, 398 DOI 10.17487/RFC8032, January 2017, 399 . 401 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 402 Algorithm (EdDSA) for DNSSEC", RFC 8080, 403 DOI 10.17487/RFC8080, February 2017, 404 . 406 Appendix A. Examples 408 [[TODO: script up generation of all samples - it's not unlikely we 409 mucked up somewhere below when generating 'em partly-manually;-)]] 411 A.1. Sample Unsigned RDBD RR 413 When example.com is the relating-domain and dept-example.com is the 414 related-domain, an unsigned RDBD RR would look like this in a zone 415 file: 417 dept-example.com. IN 3600 RDBD 0 example.com. 419 The following is equivalent to tbe above: 421 dept-example.com. IN 3600 RDBD 0 example.com. 0 0 "" 423 A.2. Sample RSA Signature 425 Appendix C of [RFC6376] has some reference material on how to create 426 a set of keys for use in this type of use case. The RSA key length 427 is recommended to be at least 2048 bits instead of the 1024 428 recommended in that appendix. 430 Creation of keys: 432 $ openssl genrsa -out rsa.private 2048 433 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 435 Sample Key: 437 rsa.private: 438 -----BEGIN RSA PRIVATE KEY----- 439 MIIEowIBAAKCAQEA2LNjBAdNAtZOMdd3hlemZF8a0onOcEo5g1KWnKzryDCfH4LZ 440 kXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly9ztBXc4obY5wnQpl4nbvOdf6vyLy 441 7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL6MDWLU9ZSWlqskzLVPgwqtT80xch 442 U65HipKkr2luSAySZyyNEf58pRea3D3pBkLy5hCDhr2+6GF2q9lJ9qMopd2P/ZXx 443 Hkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfVwrs4495a8OUkOBy7V4YkgKbFYSSk 444 GPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj1QIDAQABAoIBAH/eAgwrfq6w4/0X 445 Bgk4iQ9q6vnWpQCvW5Z40jRq+MnsnshKPrVL+krIGU/fvt7vaIzIPFTGrf7VWxl3 446 +oZg/1sRFPYUItjaluqjaxEhWvHH1saYCb2lAV1x9QtkgjBv4F6GZqfi1MJfro32 447 QP36s/hIaVjdHHNsB7BkDgr6VEVIR5y2PmW4aLjHCiqsyDIUM4zRcl4exzw+rst1 448 z2seOhhJrnYdc+VnkEg5GKENldZ3tZoY3je/OsfNJtKjpArPRqkP1qve3h3uD+PK 449 obZ7BM+xok29Fxf6AgC99eDr9BatTa/a8q7NYMkVRLq/JdOF1XUuDDNd3r93Ae4n 450 54qqucECgYEA/Xuct8ALG2/6Kd4Lmm9i055LVxdwB+1wG1JNE1IB+OI+6B8W49po 451 vK/fFVHMEV2BoRr4EB58Xxa+oICBImIzTUQXYQnMbDzL2N+X3FrkDSGCPZQy7GzD 452 wFdpY3ceNShou1bRt4/hPWLLI35ZXM3yqBJeGhbTUmYVdWrkXTNo2wUCgYEA2tpE 453 +bg9iIYUJAg/CEpdWn+8ZxhRnBDziN88Grli+arSWaMWE809GyPaeiplbwywnXRb 454 vliskE43CcgstnhRKY8dWB2AQnRESvsJKO8rw/ONSxlWTpFc78xxmmNSvOBs4Srv 455 quMc6HTMaetCM5/l0PddCY3/rls9FTESf36RXpECgYEA5AF6mHYwB4AT3/ERMtsa 456 ZAuw7Sfx58+V1Z2UItrTV1H7D8RXTKE7MO5plb2796rKXWXq2GTzrnzA/5JXldwL 457 FWc4OFsd/AY7vlpxOQ6wr3cCte1GWRAEjFCURZnyHBK7Ejgn8BuFmTfyTXzrWOUP 458 bksHRiRd9XJJvxJlU8hYexkCgYBhM9i24THTVVnUtyTn1b+o1lsjnxWAL7c674uO 459 gxCGu2w6C8leeiXNzBrZb8Mlk4lOJcQpwtDCNzsSySmy0bWas8ngvRmeam16sAzd 460 dX0Gx0HWPSasNrwEddVvMPYqlbNGPv+78quAQ4AW+zqoGzjDm1pjSAJrunJi2yzQ 461 G7MNQQKBgCZktECUg2xr8vgVTB586sB7PiHp2j8Wabxh+dMiNUEB7qg4HZdzh8XA 462 JXnJnZVQWBL0s10yPg9oITWVBcZ3MqgOqsN1QamN9KjzA46ILtpWptz2q3Nw2Tkl 463 m7RBP9R9gM9mnl9/azK7Y5uj11/O3cNJLEIWcraKqydPfvxNyEtP 464 -----END RSA PRIVATE KEY----- 465 rsa.public: 466 -----BEGIN PUBLIC KEY----- 467 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2LNjBAdNAtZOMdd3hlem 468 ZF8a0onOcEo5g1KWnKzryDCfH4LZkXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly 469 9ztBXc4obY5wnQpl4nbvOdf6vyLy7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL 470 6MDWLU9ZSWlqskzLVPgwqtT80xchU65HipKkr2luSAySZyyNEf58pRea3D3pBkLy 471 5hCDhr2+6GF2q9lJ9qMopd2P/ZXxHkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfV 472 wrs4495a8OUkOBy7V4YkgKbFYSSkGPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj 473 1QIDAQAB 474 -----END PUBLIC KEY----- 476 To calculate the key-tag as specified in Appendix B of [RFC4034] we 477 used python code from: 479 File containing to-be-signed data: 481 $ cat to-be-signed-8.txt 482 relating=example.com 483 related=foo-example.com 484 rdbd-tag=0 485 key-tag=65498 486 sig-alg=8 487 $ 488 $ od -x to-be-signed-8.txt 489 0000000 6572 616c 6974 676e 653d 6178 706d 656c 490 0000020 632e 6d6f 720a 6c65 7461 6465 643d 7065 491 0000040 2d74 7865 6d61 6c70 2e65 6f63 0a6d 6472 492 0000060 6462 742d 6761 303d 6b0a 7965 742d 6761 493 0000100 363d 3435 3839 730a 6769 612d 676c 383d 494 0000120 000a 495 0000121 497 To sign that file: 499 $ openssl dgst -sha256 -sign rsa.private \ 500 -out rsa.sig to-be-signed-8.txt 501 $ od -x rsa.sig 502 0000000 087c d5c9 375f dcba 9edf ce25 e353 9fb9 503 0000020 6ef4 ca9f a167 6d91 71bb 7487 5edd fe30 504 0000040 452e d104 724f f593 009b be3f 6006 ba77 505 0000060 c1f5 edc6 e207 7ab0 69a1 79bf 18e6 eea3 506 0000100 3562 6ca4 dc73 22c3 1e35 d15c 44be 5f63 507 0000120 ac68 f61e ea34 432d 9e12 2325 d48c 2fd9 508 0000140 330d 1caf 5761 6714 eed2 c7e2 4f71 2c1a 509 0000160 c35b e45e 833b e343 a8e2 3dbf 1a73 02a8 510 0000200 c686 7240 aa69 df68 a086 8e3e 2a02 ad57 511 0000220 32df 0e62 4679 3f4e 8afb 0716 1ad6 4300 512 0000240 03c6 429f 7b6e bf4d ecae d074 9158 99be 513 0000260 ab0e 3d49 bb42 a84a 071a b959 2d27 3eea 514 0000300 c9de 0781 dc5b e205 7708 e50b e485 0cdb 515 0000320 2fbe adee f521 3b75 9c67 66a8 d217 4f6e 516 0000340 90da 9423 9d8d e683 7110 4368 f70e 80a2 517 0000360 3a8c 25f1 3655 44a2 a585 d87d ca99 aac9 518 0000400 520 The presentation fom of a signed RDBD record (with a 3600 TTL) would 521 be: 523 dept-example.com. 3600 RDBD 0 example.com. 65498 8 ( 524 hfnhVSlTZMFltG2qU+4vyCPbfSMutxuV8zEyBv7GshOcKMOW 525 VLFBK116wRUb7wVgG9TSunXyIuCjDqtidEjWftwVZ8SsXBzo 526 tJPMq9HbvZaAnfmx4HxxAMHCpX9QJ2cOK/5VobdZm2eZnXl4 527 jd9JsLGuez2wVeiCkwk0x6z/tA61SHmDIFJb5zeKbuvbN14y 528 ABaNE88pxoj7EMVQD/nVoag2MqtsiaMS3kbvkYXC3gv25hgM 529 mzH+kRXGieaPeYly/ai8OSn3X2bksrffqPuiQsVC03UEm9Vn 530 YJgzSjnsvNXvwWJpJ9zyWmVbgdR3/vvUsz2pPvKyJsLT9Knl 531 fPNpvg== ) 533 The base64 encoded value for the signature can be produced using: 535 $ base64 -w48 rsa.sig 536 hfnhVSlTZMFltG2qU+4vyCPbfSMutxuV8zEyBv7GshOcKMOW 537 VLFBK116wRUb7wVgG9TSunXyIuCjDqtidEjWftwVZ8SsXBzo 538 tJPMq9HbvZaAnfmx4HxxAMHCpX9QJ2cOK/5VobdZm2eZnXl4 539 jd9JsLGuez2wVeiCkwk0x6z/tA61SHmDIFJb5zeKbuvbN14y 540 ABaNE88pxoj7EMVQD/nVoag2MqtsiaMS3kbvkYXC3gv25hgM 541 mzH+kRXGieaPeYly/ai8OSn3X2bksrffqPuiQsVC03UEm9Vn 542 YJgzSjnsvNXvwWJpJ9zyWmVbgdR3/vvUsz2pPvKyJsLT9Knl 543 fPNpvg== 545 To verify, with "rsa.sig" containing the above signature: 547 $ openssl dgst -sha256 -verify rsa.public \ 548 -signature rsa.sig to-be-signed.txt 549 Verified OK 551 The RDBDKEY RR for this example would be: 553 example.com. 3600 RDBDKEY 0 3 8 ( 554 LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C 555 Z2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUEy 556 TE5qQkFkTkF0Wk9NZGQzaGxlbQpaRjhhMG9uT2NFbzVnMUtX 557 bkt6cnlEQ2ZINExaa1hPUHpBSnZ6NHlLTUhXNXlrT3o5T3pH 558 TDAxR01sOG5zOEx5Cjl6dEJYYzRvYlk1d25RcGw0bmJ2T2Rm 559 NnZ5THk3R3FncCtkajZScnljU1lKZExpdGlZYXBId1J5dUtt 560 RVJsUUwKNk1EV0xVOVpTV2xxc2t6TFZQZ3dxdFQ4MHhjaFU2 561 NUhpcEtrcjJsdVNBeVNaeXlORWY1OHBSZWEzRDNwQmtMeQo1 562 aENEaHIyKzZHRjJxOWxKOXFNb3BkMlAvWlh4SGt2emwzVEZ0 563 WDZHalA1TFRzYjJkeTN0RUQ3dmJmL0V5UWZWCndyczQ0OTVh 564 OE9Va09CeTdWNFlrZ0tiRllTU2tHUG1oV29QYlY3aENRakVB 565 VVJXTE05SjdFVW91M1UxV0lxVGoKMVFJREFRQUIKLS0tLS1F 566 TkQgUFVCTElDIEtFWS0tLS0tCgo= ) 568 A.3. Sample Ed25519 Signature 570 Since OpenSSL does not yet support Ed25519 singing via its command 571 line tool, we generate our example using the python script below. 572 This uses the python library from Appendix A of [RFC8032]. 574 #!/usr/bin/env python3 575 # CODE_BEGINS 576 import sys, binascii 577 from eddsa2 import Ed25519 579 # secret chosen to be 32 octets funnily enuugh:-) 580 secret="rdbd-example0001rdbd-example0002".encode('utf-8') 581 privkey,pubkey = Ed25519.keygen(secret) 582 msg=open('to-be-signed-15.txt','r').read().encode('utf-8') 583 signature = Ed25519.sign(privkey, pubkey, msg) 585 print("private:"+ str(binascii.hexlify(privkey))) 586 print("public:"+ str(binascii.hexlify(pubkey))) 587 print("sig:"+ str(binascii.hexlify(signature))) 588 print("to-be-signed:" + str(msg)) 590 with open("ed25519.sig", "wb") as sigf: 591 sigf.write(signature) 592 with open("ed25519.pub","wb") as pubf: 593 pubf.write(pubkey) 595 # CODE_ENDS 597 The to-be-signed-15.txt file contains: 599 $ cat to-be-signed-15.txt 600 relating=example.com 601 related=dept-example.com 602 rdbd-tag=0 603 key-tag=35988 604 sig-alg=15 605 $ 607 The output when the above code is run (with some spacing added) is: 609 $ ./ed25519-signer.py 610 private: 611 b'726462642d6578616d706c6530303031 612 726462642d6578616d706c6530303032' 613 public: 614 b'353fc31e1168c91f0af65d6c26fd441f 615 b7df9671a23a746bb3ec86be8d35b648' 616 sig: 617 b'466a80ce6377b1e4bec563d85b8d55bd 618 4a51a5b91c1c1e46a9c4e22a16557c38 619 e85ccc8ac05e6046d0066c2c52b3a174 620 20b59af9627840ac312f5ab55e11be07' 621 to-be-signed: 622 b'relating=example.com\nrelated=dept-example.com\n 623 rdbd-tag=0\nkey-tag=35988\nsig-alg=15\n' 625 The presentation form for an RDBD RR would then be: 627 dept-example.com. 3600 RDBD 0 example.com. 35988 15 ( 628 RmqAzmN3seS+xWPYW41VvUpRpbkcHB5G 629 qcTiKhZVfDjoXMyKwF5gRtAGbCxSs6F0 630 ILWa+WJ4QKwxL1q1XhG+Bw== ) 632 The RDBDKEY for this example would be: 634 example.com. 3600 RDBDKEY 0 3 15 ( 635 NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRr 636 s+yGvo01tkg= ) 638 Appendix B. Changes and Open Issues 640 [[RFC editor: please delete this appendix ]] 642 B.1. Changes from -00 to -01 644 o Changed from primary/secondary to relating/related (better 645 suggestions are still welcome) 647 o Moved away from abuse of TXT RRs 649 o We now specify optional DNSSEC-like signatures (we'd be fine with 650 moving back to a more DKIM-like mechanism, but wanted to see how 651 this looked) 653 o Added Ed25519 option 655 o Re-worked and extended examples 657 B.2. Open Issues 659 Current open github issues include: 661 o #5: specify input for signing more precisely - e.g. is there a CR 662 or NULL or not 664 o #6: what, if anything, does rdbd for example.com mean for 665 foo.example.com? 667 These can be seen at: 670 Authors' Addresses 672 Alex Brotman 673 Comcast, Inc 675 Email: alex_brotman@comcast.com 677 Stephen Farrell 678 Trinity College Dublin 680 Email: stephen.farrell@cs.tcd.ie