Strong Internet Names (SIN)
draft-hallambaker-sin-01

Versions: 00 01                                                         
Network Working Group                                    P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Informational                        September 18, 2017
Expires: March 22, 2018


                      Strong Internet Names (SIN)
                        draft-hallambaker-sin-01

Abstract

   A Strong Internet Name is a DNS name that contains a cryptographic
   binding to a security policy governing interpretation of the name.
   This document describes the use of Strong Internet Names formed using
   a Uniform Data Fingerprint of a PKIX trust root and outlines the
   additional capabilities that might be supported in a purpose written
   policy language.

   This document is also available online at
   http://prismproof.org/Documents/draft-hallambaker-sin.html [1] .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 22, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Hallam-Baker             Expires March 22, 2018                 [Page 1]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Related Specifications  . . . . . . . . . . . . . . . . .   3
     2.3.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .   3
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Resolution  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Implicit Security Policy  . . . . . . . . . . . . . . . .   5
     3.3.  Explicit Security Policy  . . . . . . . . . . . . . . . .   5
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  The UDF Format  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Precision . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  UDF Strong Labels . . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     5.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document is written as a submission to the IAB workshop on
   Explicit Internet Naming Systems.  The proposal described here is a
   mechanism that allows a security policy and cryptographic root of
   trust to be introduced into any Internet identifier scheme that
   includes a DNS name without introducing new syntax.

   Strong Internet Names (SINs) bring together concepts introduced in
   the use of Strong Names introduced in the .Net security framework,
   fingerprints as used in OpenPGP and security policy description.

   Incorporating a fingerprint of a root of trust into an identifier
   produces an identifier whose interpretation is objective and does not
   depend on subjective assumptions as to whether a root of trust is
   trustworthy or not.

   Since the SIN only includes the fingerprint of the root of trust,
   rather than the root of trust itself, the process of interpretation
   will of course require a means of retrieving the additional
   information.



Hallam-Baker             Expires March 22, 2018                 [Page 2]


Internet-Draft         Strong Internet Names (SIN)        September 2017


2.  Definitions

   This section presents the related specifications and standard, the
   terms that are used as terms of art within the documents and the
   terms used as requirements language.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

2.2.  Related Specifications

   Strong Internet Names make use of the Uniform Data Fingerprint
   described in [draft-hallambaker-udf] .

2.3.  Defined Terms

   No terms of art are defined.

2.4.  Implementation Status

   The implementation status of the reference code base is described in
   the companion document [draft-hallambaker-mesh-developer] .

3.  Overview

   A SIN is an Internet Identifier that contains a fingerprint of a root
   of trust that may be used to verify the interpretation of the
   identifier.  This section describes the manner in which SINs are
   used.  The following section describes their construction using
   Uniform Data Fingerprints [I-D.hallambaker-udf]

   For example, Example Inc holds the domain name example.com and has
   deployed a private CA whose root of trust is a PKIX certificate with
   the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.

   Alice is an employee of Example Inc., she uses three email addresses:

   alice@example.com  A regular email address (not a SIN).

   alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com  A strong email
      address that is backwards compatible.

   alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz  A strong email
      address that is backwards incompatible.




Hallam-Baker             Expires March 22, 2018                 [Page 3]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   All three forms of the address are valid RFC822 addresses and may be
   used in a legacy email client, stored in an address book application,
   etc.  But the ability of a legacy client to make use of the address
   differs.  Addresses of the first type may always be used.  Addresses
   of the second type may only be used if an appropriate MX record is
   provisioned.  Addresses of the third type will always fail unless the
   resolver understands that it is a SIN requiring special processing.

   When specified as the destination address in a Mail User Application
   (MUA), these addresses have the following interpretations:

   alice@example.com  Send mail to Alice without requiring security
      enhancements.

   alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com  Send mail to
      Alice.  If the MUA is SIN-Aware, it MUST resolve the security
      policy specified by the fingerprint and apply security
      enhancements as mandated by that policy.

   alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz  Only send mail
      to Alice if the MUA is SIN-Aware, it MUST resolve the security
      policy specified by the fingerprint and apply security
      enhancements as mandated by that policy.

   These rules allow Bob to send email to Alice with either ?best
   effort? security or mandatory security as the circumstances demand.

3.1.  Resolution

   Since a SIN only contains the fingerprint of a root of trust rather
   than the root of trust itself, a mechanism is required to resolve the
   root of trust from the fingerprint.  The mechanism by which this is
   achieved is outside the scope of this document.

   The Mathematical Mesh [I-D.hallambaker-mesh-architecture] is an
   infrastructure that is designed to resolve fingerprints to policy.
   But it is not necessarily the case that an entirely new
   infrastructure is required.  The Mesh architecture was conceived as a
   means of achieving resolution of a SIN at a very granular level.  In
   the Mesh, every user is their own personal root of trust and decides
   which resources and trust providers to delegate decisions to.

   For cases in which we do not require resolution of security policy
   with resolution finer than a DNS domain, the DNS may be used for
   resolution using the existing CERT record [RFC4398]






Hallam-Baker             Expires March 22, 2018                 [Page 4]


Internet-Draft         Strong Internet Names (SIN)        September 2017


3.2.  Implicit Security Policy

   A security policy may be implicit or explicit depending on the root
   of trust referenced and the context in which it is used.

   Since many Internet applications are already designed to make use of
   a PKIX based trust infrastructure, the fingerprint of a PKIX root of
   trust provides sufficient information to deduce an appropriate
   security policy in many instances.  For example:

   https://mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com/  Connect to
      example.com using a TLS connection with a certificate that is
      valid in a chain of trust that contains a certificate with the
      fingerprint mb2gk.

   IMAP Server: mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com  Connect to
      the IMAP server example.com over a TLS connection with a
      certificate that is valid in a chain of trust that contains a
      certificate with the fingerprint mb2gk.

   mailto:alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz  Encrypt
      mail messages using S/MIME using an S/MIME certificate that is
      valid in a chain of trust that contains a certificate with the
      fingerprint mb2gk.

3.3.  Explicit Security Policy

   While the implicit security policy model is sufficient for some
   purposes, it is less than ideal.  An explicit security policy
   language permits much more detailed policy descriptions and links to
   resources that allow the policy to be realized.

   A comprehensive security policy for Example Inc. should contain:

   o  The public key for the DNSSEC root of trust for example.com

   o  The public key for the DNSSEC root of trust for the DNS root

   o  The roots of trust for TLS, S/MIME, etc.

   o  The set of WebPKI trust roots to be trusted by Web browsers.

   o  The security enhancements (S/MIME, OpenPGP) to be applied to
      messages.

   o  Security requirements for specific services (e.g. must use TLS for
      inbound SMTP)




Hallam-Baker             Expires March 22, 2018                 [Page 5]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   Security policy may also be specified for particular applications.
   For example, an email security policy for an individual user might
   specify:

   o  Message security format (OpenPGP, S/MIME) and encryption key(s)

   o  Authentication requirement(s)

   o  Content restrictions (e.g. no executable attachments)

   It is very likely that to mitigate abuse a user would specify
   separate security policies for known and unknown senders so that use
   of end-to-end messaging, transfer of executable attachments, etc. are
   restricted to authorized senders.

   One option for expressing explicit security policy is to encode the
   information in the DNS.  Another, likely to be more satisfactory is
   to design a language for describing security policy.

4.  Specification

   The specification consists of three parts, the description of the
   fingerprint format itself, the means of encoding fingerprints within
   DNS names and the means of describing the security policy.

4.1.  The UDF Format

   The Uniform Data Fingerprint (UDF) format was designed to provide
   common format for representing fingerprints of data objects formed
   using a cryptographic digest function such as SHA-2 that was easier
   on the eye than existing URI schemes such as ni.  A UDF fingerprint
   is formed using Base32 with optional digit separators to improve
   readability.  The following is an example of a UDF:

   mb2gk-6duf5-ygyyl-jny5e-rwshz-sv75j

   Unlike traditional fingerprints calculated from the digest of the
   data itself, a UDF is a strong function of both the referenced data
   and the IANA content type.

   Fingerprint = <Version-ID> + H (<Content-ID> + ':' + H (<Data>))

   This approach provides semantic separation between domains.  This is
   necessary to defeat substitution attacks such as presenting an
   artfully constructed PKIX certificate in a context where a JSON data
   structure is expected.





Hallam-Baker             Expires March 22, 2018                 [Page 6]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   The Version-ID parameter specifies both the digest function and the
   method of application.  Version-IDs are currently defined for SHA-
   2-512 and SHA-3-512.  The values of these code points have been
   intentionally chosen to cause the first digit to be either an M
   (Merkle-Damgard) or an S (Sponge).

   The specification allows for fingerprint compression in the case that
   the leading 25, 40, 50 or 55 bits are all zero.  This allows a
   fingerprint of a public key represented in 20 characters (120 bits)
   to present the same work factor to the attacker as a 25 character
   fingerprint but at the cost of accepting a 225 increase in key
   generation difficulty.

4.2.  Precision

   A UDF fingerprint may be specified at any level of precision with the
   proviso that the work factor of a fingerprint must never be less than
   2117 operations.  The precision of a fingerprint may be reduced by
   simply truncating the text presentation.

   Since verification of a fingerprint requires the verifier to compute
   the full SHA-2-512 hash value, an application may ?strengthen? the
   fingerprint by storing it with higher precision (provided this does
   not cause a field length limit to be exceeded.

   For example, to configure her outbound email address, Alice enters
   the following as her email address:

   mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com

   The client resolves and verifies the root of trust and records the
   following in the configuration file:

   Service: example.com

   Trust-root: mb2gk-6duf5-ygyyl-jny5e-rwshz-sv75j-c4ozq-5gin2

   This presents a work factor of 2192 for subsequent interactions while
   only requiring the user to type enough digits for a 2117 .

4.3.  UDF Strong Labels

   A Strong Internet Name is a DNS name in which one of the labels is a
   prefixed UDF fingerprint of a document describing the security policy
   governing interpretation of the name.

   For example, we may form a strong internet name from the fingerprint
   above as follows:



Hallam-Baker             Expires March 22, 2018                 [Page 7]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com

   example.com.mm--.mb2gk-6duf5-ygyyl-jny5e-rwshz

   The use of a prefix of the form xx-- to identify a DNS label with a
   special interpretation was introduced to support internationalized
   DNS names.  The MM?prefix is proposed as Strong Internet Names were
   originally developed as part of the Mathematical Mesh which builds on
   and extends the capabilities of strong names.

   The placement of the UDF entry in the string has no effect on
   semantics but does affect resolution.  In the first strong name, the
   fingerprint appears at the leftmost of the name allowing it to be
   resolved by any Internet application (provided the necessary DNS
   records are provisioned).  In the second case, the fingerprint
   appears as the root element.  This means that the name cannot be
   resolved by an application unless either the application or the DNS
   resolution service it uses understands that the name is a SIN.

5.  References

5.1.  Normative References

   [draft-hallambaker-udf]
              Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft-
              hallambaker-udf-06 (work in progress), August 2017.

   [I-D.hallambaker-udf]
              Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft-
              hallambaker-udf-06 (work in progress), August 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997.

   [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name
              System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006.

5.2.  Informative References

   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", draft-hallambaker-mesh-developer-04 (work
              in progress), September 2017.







Hallam-Baker             Expires March 22, 2018                 [Page 8]


Internet-Draft         Strong Internet Names (SIN)        September 2017


   [I-D.hallambaker-mesh-architecture]
              Hallam-Baker, P., "Mathematical Mesh: Architecture",
              draft-hallambaker-mesh-architecture-03 (work in progress),
              May 2017.

5.3.  URIs

   [1] http://prismproof.org/Documents/draft-hallambaker-sin.html

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com




































Hallam-Baker             Expires March 22, 2018                 [Page 9]