idnits 2.17.1 draft-hallambaker-sin-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2017) is 2405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 388 == Outdated reference: A later version (-12) exists of draft-hallambaker-udf-06 == Outdated reference: A later version (-22) exists of draft-hallambaker-mesh-architecture-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational September 18, 2017 5 Expires: March 22, 2018 7 Strong Internet Names (SIN) 8 draft-hallambaker-sin-01 10 Abstract 12 A Strong Internet Name is a DNS name that contains a cryptographic 13 binding to a security policy governing interpretation of the name. 14 This document describes the use of Strong Internet Names formed using 15 a Uniform Data Fingerprint of a PKIX trust root and outlines the 16 additional capabilities that might be supported in a purpose written 17 policy language. 19 This document is also available online at 20 http://prismproof.org/Documents/draft-hallambaker-sin.html [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 22, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Related Specifications . . . . . . . . . . . . . . . . . 3 60 2.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Resolution . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Implicit Security Policy . . . . . . . . . . . . . . . . 5 65 3.3. Explicit Security Policy . . . . . . . . . . . . . . . . 5 66 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. The UDF Format . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Precision . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. UDF Strong Labels . . . . . . . . . . . . . . . . . . . . 7 70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 5.2. Informative References . . . . . . . . . . . . . . . . . 8 73 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 This document is written as a submission to the IAB workshop on 79 Explicit Internet Naming Systems. The proposal described here is a 80 mechanism that allows a security policy and cryptographic root of 81 trust to be introduced into any Internet identifier scheme that 82 includes a DNS name without introducing new syntax. 84 Strong Internet Names (SINs) bring together concepts introduced in 85 the use of Strong Names introduced in the .Net security framework, 86 fingerprints as used in OpenPGP and security policy description. 88 Incorporating a fingerprint of a root of trust into an identifier 89 produces an identifier whose interpretation is objective and does not 90 depend on subjective assumptions as to whether a root of trust is 91 trustworthy or not. 93 Since the SIN only includes the fingerprint of the root of trust, 94 rather than the root of trust itself, the process of interpretation 95 will of course require a means of retrieving the additional 96 information. 98 2. Definitions 100 This section presents the related specifications and standard, the 101 terms that are used as terms of art within the documents and the 102 terms used as requirements language. 104 2.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119] . 110 2.2. Related Specifications 112 Strong Internet Names make use of the Uniform Data Fingerprint 113 described in [draft-hallambaker-udf] . 115 2.3. Defined Terms 117 No terms of art are defined. 119 2.4. Implementation Status 121 The implementation status of the reference code base is described in 122 the companion document [draft-hallambaker-mesh-developer] . 124 3. Overview 126 A SIN is an Internet Identifier that contains a fingerprint of a root 127 of trust that may be used to verify the interpretation of the 128 identifier. This section describes the manner in which SINs are 129 used. The following section describes their construction using 130 Uniform Data Fingerprints [I-D.hallambaker-udf] 132 For example, Example Inc holds the domain name example.com and has 133 deployed a private CA whose root of trust is a PKIX certificate with 134 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 136 Alice is an employee of Example Inc., she uses three email addresses: 138 alice@example.com A regular email address (not a SIN). 140 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email 141 address that is backwards compatible. 143 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email 144 address that is backwards incompatible. 146 All three forms of the address are valid RFC822 addresses and may be 147 used in a legacy email client, stored in an address book application, 148 etc. But the ability of a legacy client to make use of the address 149 differs. Addresses of the first type may always be used. Addresses 150 of the second type may only be used if an appropriate MX record is 151 provisioned. Addresses of the third type will always fail unless the 152 resolver understands that it is a SIN requiring special processing. 154 When specified as the destination address in a Mail User Application 155 (MUA), these addresses have the following interpretations: 157 alice@example.com Send mail to Alice without requiring security 158 enhancements. 160 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com Send mail to 161 Alice. If the MUA is SIN-Aware, it MUST resolve the security 162 policy specified by the fingerprint and apply security 163 enhancements as mandated by that policy. 165 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz Only send mail 166 to Alice if the MUA is SIN-Aware, it MUST resolve the security 167 policy specified by the fingerprint and apply security 168 enhancements as mandated by that policy. 170 These rules allow Bob to send email to Alice with either ?best 171 effort? security or mandatory security as the circumstances demand. 173 3.1. Resolution 175 Since a SIN only contains the fingerprint of a root of trust rather 176 than the root of trust itself, a mechanism is required to resolve the 177 root of trust from the fingerprint. The mechanism by which this is 178 achieved is outside the scope of this document. 180 The Mathematical Mesh [I-D.hallambaker-mesh-architecture] is an 181 infrastructure that is designed to resolve fingerprints to policy. 182 But it is not necessarily the case that an entirely new 183 infrastructure is required. The Mesh architecture was conceived as a 184 means of achieving resolution of a SIN at a very granular level. In 185 the Mesh, every user is their own personal root of trust and decides 186 which resources and trust providers to delegate decisions to. 188 For cases in which we do not require resolution of security policy 189 with resolution finer than a DNS domain, the DNS may be used for 190 resolution using the existing CERT record [RFC4398] 192 3.2. Implicit Security Policy 194 A security policy may be implicit or explicit depending on the root 195 of trust referenced and the context in which it is used. 197 Since many Internet applications are already designed to make use of 198 a PKIX based trust infrastructure, the fingerprint of a PKIX root of 199 trust provides sufficient information to deduce an appropriate 200 security policy in many instances. For example: 202 https://mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com/ Connect to 203 example.com using a TLS connection with a certificate that is 204 valid in a chain of trust that contains a certificate with the 205 fingerprint mb2gk. 207 IMAP Server: mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com Connect to 208 the IMAP server example.com over a TLS connection with a 209 certificate that is valid in a chain of trust that contains a 210 certificate with the fingerprint mb2gk. 212 mailto:alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz Encrypt 213 mail messages using S/MIME using an S/MIME certificate that is 214 valid in a chain of trust that contains a certificate with the 215 fingerprint mb2gk. 217 3.3. Explicit Security Policy 219 While the implicit security policy model is sufficient for some 220 purposes, it is less than ideal. An explicit security policy 221 language permits much more detailed policy descriptions and links to 222 resources that allow the policy to be realized. 224 A comprehensive security policy for Example Inc. should contain: 226 o The public key for the DNSSEC root of trust for example.com 228 o The public key for the DNSSEC root of trust for the DNS root 230 o The roots of trust for TLS, S/MIME, etc. 232 o The set of WebPKI trust roots to be trusted by Web browsers. 234 o The security enhancements (S/MIME, OpenPGP) to be applied to 235 messages. 237 o Security requirements for specific services (e.g. must use TLS for 238 inbound SMTP) 240 Security policy may also be specified for particular applications. 241 For example, an email security policy for an individual user might 242 specify: 244 o Message security format (OpenPGP, S/MIME) and encryption key(s) 246 o Authentication requirement(s) 248 o Content restrictions (e.g. no executable attachments) 250 It is very likely that to mitigate abuse a user would specify 251 separate security policies for known and unknown senders so that use 252 of end-to-end messaging, transfer of executable attachments, etc. are 253 restricted to authorized senders. 255 One option for expressing explicit security policy is to encode the 256 information in the DNS. Another, likely to be more satisfactory is 257 to design a language for describing security policy. 259 4. Specification 261 The specification consists of three parts, the description of the 262 fingerprint format itself, the means of encoding fingerprints within 263 DNS names and the means of describing the security policy. 265 4.1. The UDF Format 267 The Uniform Data Fingerprint (UDF) format was designed to provide 268 common format for representing fingerprints of data objects formed 269 using a cryptographic digest function such as SHA-2 that was easier 270 on the eye than existing URI schemes such as ni. A UDF fingerprint 271 is formed using Base32 with optional digit separators to improve 272 readability. The following is an example of a UDF: 274 mb2gk-6duf5-ygyyl-jny5e-rwshz-sv75j 276 Unlike traditional fingerprints calculated from the digest of the 277 data itself, a UDF is a strong function of both the referenced data 278 and the IANA content type. 280 Fingerprint = + H ( + ':' + H ()) 282 This approach provides semantic separation between domains. This is 283 necessary to defeat substitution attacks such as presenting an 284 artfully constructed PKIX certificate in a context where a JSON data 285 structure is expected. 287 The Version-ID parameter specifies both the digest function and the 288 method of application. Version-IDs are currently defined for SHA- 289 2-512 and SHA-3-512. The values of these code points have been 290 intentionally chosen to cause the first digit to be either an M 291 (Merkle-Damgard) or an S (Sponge). 293 The specification allows for fingerprint compression in the case that 294 the leading 25, 40, 50 or 55 bits are all zero. This allows a 295 fingerprint of a public key represented in 20 characters (120 bits) 296 to present the same work factor to the attacker as a 25 character 297 fingerprint but at the cost of accepting a 225 increase in key 298 generation difficulty. 300 4.2. Precision 302 A UDF fingerprint may be specified at any level of precision with the 303 proviso that the work factor of a fingerprint must never be less than 304 2117 operations. The precision of a fingerprint may be reduced by 305 simply truncating the text presentation. 307 Since verification of a fingerprint requires the verifier to compute 308 the full SHA-2-512 hash value, an application may ?strengthen? the 309 fingerprint by storing it with higher precision (provided this does 310 not cause a field length limit to be exceeded. 312 For example, to configure her outbound email address, Alice enters 313 the following as her email address: 315 mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com 317 The client resolves and verifies the root of trust and records the 318 following in the configuration file: 320 Service: example.com 322 Trust-root: mb2gk-6duf5-ygyyl-jny5e-rwshz-sv75j-c4ozq-5gin2 324 This presents a work factor of 2192 for subsequent interactions while 325 only requiring the user to type enough digits for a 2117 . 327 4.3. UDF Strong Labels 329 A Strong Internet Name is a DNS name in which one of the labels is a 330 prefixed UDF fingerprint of a document describing the security policy 331 governing interpretation of the name. 333 For example, we may form a strong internet name from the fingerprint 334 above as follows: 336 mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com 338 example.com.mm--.mb2gk-6duf5-ygyyl-jny5e-rwshz 340 The use of a prefix of the form xx-- to identify a DNS label with a 341 special interpretation was introduced to support internationalized 342 DNS names. The MM?prefix is proposed as Strong Internet Names were 343 originally developed as part of the Mathematical Mesh which builds on 344 and extends the capabilities of strong names. 346 The placement of the UDF entry in the string has no effect on 347 semantics but does affect resolution. In the first strong name, the 348 fingerprint appears at the leftmost of the name allowing it to be 349 resolved by any Internet application (provided the necessary DNS 350 records are provisioned). In the second case, the fingerprint 351 appears as the root element. This means that the name cannot be 352 resolved by an application unless either the application or the DNS 353 resolution service it uses understands that the name is a SIN. 355 5. References 357 5.1. Normative References 359 [draft-hallambaker-udf] 360 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 361 hallambaker-udf-06 (work in progress), August 2017. 363 [I-D.hallambaker-udf] 364 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 365 hallambaker-udf-06 (work in progress), August 2017. 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. 371 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 372 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006. 374 5.2. Informative References 376 [draft-hallambaker-mesh-developer] 377 Hallam-Baker, P., "Mathematical Mesh: Reference 378 Implementation", draft-hallambaker-mesh-developer-04 (work 379 in progress), September 2017. 381 [I-D.hallambaker-mesh-architecture] 382 Hallam-Baker, P., "Mathematical Mesh: Architecture", 383 draft-hallambaker-mesh-architecture-03 (work in progress), 384 May 2017. 386 5.3. URIs 388 [1] http://prismproof.org/Documents/draft-hallambaker-sin.html 390 Author's Address 392 Phillip Hallam-Baker 393 Comodo Group Inc. 395 Email: philliph@comodo.com