Internet DRAFT - draft-hallambaker-mesh-naming

draft-hallambaker-mesh-naming







Network Working Group                                    P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Informational                           August 12, 2017
Expires: February 13, 2018


                    Naming in the Mathematical Mesh.
                    draft-hallambaker-mesh-naming-00

Abstract

   The importance of naming in information systems is explained with
   reference to a typical use case.  Existing Internet naming systems
   attempt to strike a balance between usability and machine
   readability.  An alternative approach in which separate classes of
   identifiers are introduced for human and machine interaction is
   described.  Human Interaction Identifiers are interpreted in the
   context in which they are used and are thus more compact and offer a
   superior user experience.  Strong Internet Names are a form of
   Machine Interaction Identifier that are backwards compatible with
   existing Internet names that include a DNS address and are
   cryptographically bound to a security policy governing
   interpretation.  The application of these approaches in the
   Mathematical Mesh is described.

   This document is also available online at
   http://prismproof.org/Documents/draft-hallambaker-mesh-naming.html .

Status of This Memo

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

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

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

   This Internet-Draft will expire on February 13, 2018.







Hallam-Baker            Expires February 13, 2018               [Page 1]

Internet-Draft          Mathematical Mesh Naming             August 2017


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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Identifiers and Naming  . . . . . . . . . . . . . . . . .   4
   2.  Identifiers in the Mathematical Mesh. . . . . . . . . . . . .   6
     2.1.  Human Interaction Identifiers . . . . . . . . . . . . . .   7
       2.1.1.  User Expectation  . . . . . . . . . . . . . . . . . .   8
     2.2.  Machine Interaction Identifiers . . . . . . . . . . . . .   9
     2.3.  Mapping Human Interaction to Machine  . . . . . . . . . .  10
   3.  Strong Internet Names . . . . . . . . . . . . . . . . . . . .  12
     3.1.  UDF Fingerprint . . . . . . . . . . . . . . . . . . . . .  12
     3.2.  Strong Email Addresses  . . . . . . . . . . . . . . . . .  13
     3.3.  Network Administration  . . . . . . . . . . . . . . . . .  14
     3.4.  Security Policy Specification . . . . . . . . . . . . . .  16
     3.5.  Resolving SINs  . . . . . . . . . . . . . . . . . . . . .  17
   4.  Personal Mesh . . . . . . . . . . . . . . . . . . . . . . . .  18
     4.1.  Connecting Devices  . . . . . . . . . . . . . . . . . . .  19
     4.2.  Connecting Applications . . . . . . . . . . . . . . . . .  20
     4.3.  Contacts Directory  . . . . . . . . . . . . . . . . . . .  20
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     6.1.  Expectations  . . . . . . . . . . . . . . . . . . . . . .  21
     6.2.  Work Factor . . . . . . . . . . . . . . . . . . . . . . .  21
     6.3.  Authority . . . . . . . . . . . . . . . . . . . . . . . .  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  22
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Use Case

   Hollywood Alice arrives at the airport.  Her hire car is already
   waiting for her at the curb, every aspect of its function precisely
   matched to her preferences.  The radio is tuned to her favorite



Hallam-Baker            Expires February 13, 2018               [Page 2]

Internet-Draft          Mathematical Mesh Naming             August 2017


   station, the seats, mirrors and driving controls adapt to her
   measurements and of course, the navigation system is already
   programed with her itinerary.

   On the way to her destination, Hollywood Alice places a conference
   call to Bob and Carol by speaking their name.  Bob wants to know if
   Alice?s new camera arrived in time for her trip.  It did, but only
   just.  Alice had only a few minutes to unwrap it and pack it for her
   trip.  Carol has been to the area before and tells Alice she must see
   the Golden Gate bridge from Baker Beach, the same spot that Ansel
   Adams took his famous landscapes before and after the bridge was
   built.  The navigator updates its route accordingly and Alice arrives
   in the golden hour.

   Her camera is a large modern DSLR but it doesn?t have a GPS, it
   doesn?t need one as it automatically captures this data from her
   mobile phone via Bluetooth.  Alice joins the camera to the conference
   and it uses the same connection to upload thumbnails of her pictures
   for Bob and Carol.  When she gets to her hotel room, the camera will
   upload the raw files to Alice?s personal cloud using the high-speed
   connection.

   It all works so much better in Hollywood.

   An extremely wealthy real-world Alice being followed by a minibus
   containing a road crew of a half dozen IT support staff might
   possibly be able to create a similar user experience today but even
   that is doubtful.  Instead of taking pictures of the Golden Gate
   bridge at sunset, Real-world Alice is far more likely to find herself
   at the side of the road debugging Perl scripts or more likely,
   turning all the ?labor-saving? technology off because it simply isn?t
   worth the hassle.  We have all the parts but they just don?t fit
   together properly and even when they appear to be joined, they often
   come apart.  A ?seamless user experience? that isn?t actually
   seamless makes things worse, not better.

   There are many reasons that the scenario described above remains a
   pipe dream, not least the commercial interests of the technology
   providers.  But one of the biggest obstacles to providing the
   seamless integration experienced by Hollywood Alice is the lack of a
   secure naming infrastructure.  Providing Alice with a seamless user
   experience required seven data exchanges and ten trust relationships.









Hallam-Baker            Expires February 13, 2018               [Page 3]

Internet-Draft          Mathematical Mesh Naming             August 2017


   [[This figure is not viewable in this format.  The figure is
   available at http://prismproof.org/Documents/draft-hallambaker-mesh-
   naming.html.]]


   Information flows in the Hollywood Alice scenario.

   The only infrastructures currently capable of managing those trust
   relationships would require Alice to be in constant communication
   with some form of ?identity provider? and to surrender a large part
   of her personal control to that infrastructure.

   There are proprietary infrastructures that provide an approximation
   of the user experience if Alice buys all her devices from the same
   vendor.  But these require Alice to surrender even more personal
   control and in any case, there is no single company that makes
   phones, DSLR cameras and rents cars.  And even if such a company
   existed, Alice would not be able to achieve seamless connectivity to
   Bob and Carol unless they live in the same walled garden as Alice.

   This document explores the problem of secure naming and describes the
   approach to naming taken in the Mathematical Mesh, a Personal Public
   Key Infrastructure (PPKI) that is designed to make computers easier
   to use by making them more secure.

   The central idea is this: Current Internet identifiers are designed
   to provide a balance between human and machine use.  Separating the
   functions allows a vastly more satisfactory user experience, in most
   cases the name of the intended referent being implicit from the
   context in which it is used.  The key to making this approach
   practical being the introduction of a new form of very explicit
   identifier which is cryptographically bound to the context in which
   it is interpreted but is nevertheless backwards compatible with
   existing Internet identifiers through the use of DNS prefixing.

1.1.  Identifiers and Naming

   In the field of semiotics, a name is a symbol whose meaning is purely
   conventional, that is the meaning of the name is based on nothing
   more than a common agreement to interpret it in a specific way.  Most
   network identifiers are based on a name of some sort whether they be
   example.com or 127.0.0.1.  The proper functioning of the Internet
   depends on all the participants agreeing on a common interpretation
   of these identifiers which in turn gives rise for the need for naming
   authorities.

   Since a name is merely the result of an agreement, any naming scheme
   must be governed by an authority, even if that authority is just the



Hallam-Baker            Expires February 13, 2018               [Page 4]

Internet-Draft          Mathematical Mesh Naming             August 2017


   one person who uses the names.  The question of authority is thus an
   inescapable one when considering the security properties of naming
   schemes.

   One of the core technologies that made the World Wide Web possible
   was the realization that the means to resolve any network resource
   may be specified by means of a triple, {what, where, how}. The
   Uniform Resource Locator (URL) [RFC3986] [RFC3986] is simply a syntax
   for expressing this triple in a single identifier: how://where/what.
   It seems intuitively obvious that whether these are expressed as one
   single unit or three ?should? make no difference.  But the lightning
   success of the World Wide Web proves that combining all the
   information necessary into a single identifier makes all the
   difference in the world.

   While a URL contains a name component, it is not a pure name: The
   interpretation of the where component is intersubjectively determined
   by the choice of ICANN as the ultimate DNS naming authority, the
   interpretation of what and how is determined by the protocol
   specifications.  Different users attempting to resolve
   http://example.com/ in different parts of the world may not receive
   back the same exact sequence of bytes but provided they are connected
   to ?the Internet? they should receive back a representation of the
   same ?network resource?.

   Interpretation of the other type of Internet identifier users
   commonly encounter, the email address, is not so straightforward.
   Unlike a URL, the RFC822 email address does not contain a how
   component.  It is implicit that alice@example.com is an SMTP email
   address, but this is only one of many ways in which it may be used
   today:

   o  Send SMTP email

   o  Initiate an XMPP chat

   o  Web site username

   o  Initiate a proprietary chat

   o  Comment on a Web forum

   From the user?s perspective, it is natural to assume that the address
   alice@example.com is held by the same individual in each of these
   contexts.  But like many aspects of the Internet today, it is a
   mistaken assumption.  The holder of the email address may or may not
   be the same as the person who responds when a chat session is
   initiated.



Hallam-Baker            Expires February 13, 2018               [Page 5]

Internet-Draft          Mathematical Mesh Naming             August 2017


   An RFC822 email address is a combination of two names issued by
   separate authorities who@where.  Since the where component is a DNS
   name, there is a certain degree of consistency in interpretation
   through the infrastructure managed by ICANN.  No such guarantees are
   provided for the interpretation of who.  A site may have a policy
   preventing reissue of account names to new users or it may not.

   The use of email addresses as identifiers on third party sites
   introduces a third authority.  For example, Alice may use her email
   address alice@example.com as her account identifier for the chat
   service provided by example.net.  Resolution of the name example.com
   is now controlled by the unseen third authority example.net but only
   within the context of the example.net chat application.

   While these concerns may appear abstract, the security consequences
   are anything but.  It is the fact that alice@example.com could be the
   same person or different people that makes the Hollywood Alice
   experience unreachable today.  Alice?s phone can?t integrate with her
   hire car or her camera or her cloud communications provider because
   they lack a common language for securely identifying themselves as
   belonging to Alice.

   The identifiers we use in the Internet today represent a compromise
   between expressiveness and usability.  The more information we
   attempt to pack into an identifier, the more a user must remember or
   type or read.  If we are to introduce a cryptographically secure
   identifier it must therefore be a subclass of identifier, an
   identifier which is usually if not always hidden ?under the covers?
   and is separate from the names that the user sees and interacts with.
   This is the purpose that the Mathematical Mesh PPKI serves.

2.  Identifiers in the Mathematical Mesh.

   The Mathematical Mesh [draft-hallambaker-mesh-architecture]
   [draft-hallambaker-mesh-architecture] is a PPKI that manages two
   types of identifies: Human-Interaction identifiers which are
   primarily designed to support human interaction and Machine-
   Interaction identifiers which are primarily designed to support
   interactions between machines.

   As we saw in the previous section, these categories are not
   necessarily exclusive.  Most of Internet names used on the Internet
   today were designed to provide a compromise between human and machine
   interactions.  Such a compromise is not practical in a cryptographic
   infrastructure such as the Mesh since there is really no way to make
   an identifier that presents a cryptographic work factor of 2118 or
   better human friendly except by mapping it to another identifier
   designed for human use.



Hallam-Baker            Expires February 13, 2018               [Page 6]

Internet-Draft          Mathematical Mesh Naming             August 2017


   This section first describes the two types of identifier used in the
   Mesh and how one may be mapped to the other.  The following sections
   describe the implementation of these ideas in the current
   implementation of the Mesh.

2.1.  Human Interaction Identifiers

   Human Interaction identifiers come in many different forms and a
   given user may use multiple identifiers to refer to the same entity
   in different contexts.  Three different uses are distinguished:

      An identifier that the human user uses when entering a command.
      (e.g. ?conference Bob and Carol?)

      An identifier that is presented to the human user when requesting
      user interaction. (e.g. ?Alice Cryptographer is calling?)

      An output identifier that is used only to determine if two things
      are the same.  Comparison identifiers are used in the Mesh when
      connecting a device to a profile.

   Depending on the circumstances in which the identifiers are used, it
   is generally desirable that input identifiers be as compact as
   possible while output identifiers may provide more information.  If
   Bob receives the conference request from Carol on his smartphone it
   is probably desirable for the display to present both the shortcut
   identifier from his personal contact directory ?Alice? and her full
   personal name ?Alice Cryptographer?.

   While most identifier forms used for input (text, voice) may also be
   used for output, the reverse is not true.  A validated image of a
   subject?s trademark, as supported by the PKIX logotype extension
   [RFC3709] [RFC3709] provides a powerful means of telling a user which
   party operates the site they are visiting but would be highly
   impractical as an input format.

   The Mathematical Mesh makes use of three different types of human-
   interaction identifier:

      An identifier that is intended to be globally unambiguous. (e.g.
      alice@example.com)

      An identifier that is only unambiguous within a specific context
      (e.g. ?conference Bob and Carol?)

      An identifier whose referent is defined by the context in which it
      is used (e.g. ?localhost?)




Hallam-Baker            Expires February 13, 2018               [Page 7]

Internet-Draft          Mathematical Mesh Naming             August 2017


   For most human interactions, it is desirable to use the shortest
   identifier possible for input that does not lead to ambiguity.  Thus,
   the use of contextual identifiers is generally preferred over global
   identifiers and the use of implicit identifiers is almost always
   best.

   Most of the identifiers used in the ?Hollywood Alice? scenario were
   implicit identifiers.  The devices Alice used understood the target
   of the commands she gave by the context in which she used them.  As
   will be seen, the introduction of Strong Internet Names at the
   machine level allows them to be eliminated at the human level.

   The only contextual identifiers that Alice used were ?Bob? and
   ?Carol? which were names from Alice?s personal contacts directory.
   There are many Bobs in the world but only one ?Bob? in Alice?s
   contact book.

   The Hollywood Alice scenario only involved three people and a set of
   devices owned or rented by Alice.  There was no need for global
   identifiers because the scenario did not require Alice to interact
   with the wider world.  But it is the ability to communicate and
   interact on a global scale that gives the Internet its full power.
   It is the ability to establish secure communication with practically
   anyone in the world that makes the Internet the primary engine of
   international commerce.  It is also the capability that gives rise to
   most Internet security concerns.

2.1.1.  User Expectation

   One of the chief differences between human interaction identifiers
   and machine interaction identifiers is that humans interact with
   certain expectations that may or may not be met.  It is the
   manipulation of the user?s expectations that enables many types of
   phishing fraud.

   If a user sees a message that appears to come from a financial
   institution that they have a business relationship with and that
   expectation is not met, the result is likely to be some form of fraud
   on the user.  Such failures are always and only the fault of the
   designers of the communications infrastructure.  The user is never
   negligent, the user is never at fault if their action is the result
   of a good faith expectation of a different result.

   When the Internet was new, it was often viewed as creating a reality
   that was distinct and different from the ?real? offline world.  While
   this point of view is still a common position among Internet protocol
   designers, it is no longer the case for an increasing proportion of
   users.  The Internet existed before they did, they have been using



Hallam-Baker            Expires February 13, 2018               [Page 8]

Internet-Draft          Mathematical Mesh Naming             August 2017


   the Internet since before they could talk.  For the Internet
   generation, there is no online world, only the world.

   It is the fact that human interaction identifiers are bound to
   expectations that give rise to security concerns in defining the
   mapping from human interaction identifiers to machine.  If we are to
   avoid the need to deal with expectations in the interpretation of
   Machine Interaction Identifiers, we must use cryptography.

2.2.  Machine Interaction Identifiers

   Traditional Internet names are designed to achieve a balance between
   human and machine interaction.  As a result, these identifiers omit
   much of the context that we require at the machine level to avoid the
   need to address the issue of expectations.

   For example, the identifier https://example.com/ specifies a resource
   that is to be retrieved by means of a TLS secured conversation but
   not the trust context in which the communication is to be
   established.  While this is an acceptable, and in many cases an
   unavoidable situation for a human interaction identifier, it is a
   circumstance that is often unacceptable in the Internet of Things.

   Take for example, a high-risk process control application such as the
   placement of control rods in a nuclear reactor.  A control loop
   critical to plant safety is governed by means of a three-term (PID)
   controller connected to a temperature sensor, an actuator and the
   Supervisory Control and Data Acquisition (SCADA) system.  We would
   wish for it to be possible for all these communications to be secured
   cryptographically but we are required by regulation to account for
   the correct operation of any infrastructure on which we rely.  The
   introduction of any Trusted Third Party role whether that be a WebPKI
   CA or a ICANN managing the DNSSEC, is going to be unacceptable.

   The Mathematical Mesh introduces a new form of name, the Strong
   Internet Name (SIN).  A SIN is a name that is cryptographically bound
   to a security policy government the interpretation of the name.  The
   use of a SIN is thus bound to a specific trust context.

   The use of SINs in Mesh enabled applications closely resembles the
   use of DNS names and IP addresses at the network level.  In normal
   circumstances, the user only interacts with DNS names which are a
   name designed for human interaction.  But the Internet core has no
   understanding or knowledge of DNS names.  The only identifiers
   understood at the narrow waist are IP Addresses and so we must
   translate the DNS names to IP addresses to establish Internet
   communications.




Hallam-Baker            Expires February 13, 2018               [Page 9]

Internet-Draft          Mathematical Mesh Naming             August 2017


2.3.  Mapping Human Interaction to Machine

   To make use of a Human Interaction Identifier, it must be first
   mapped to Machine Interaction identifier.  We consider this mapping
   to be secure if and only if this translation meets the good-faith
   expectations of the user.  If a user encounters a Human Interaction
   identifier that leads the user to reasonably expect that they will be
   interacting with their bank, this expectation must be met or a
   serious security vulnerability is created.

   The terms ?reasonable expectation? and ?good-faith? are of course
   subjective but not entirely without meaning.  The various financial
   institutions that support the use of non-cash payments in the US
   operate under rules that absolve the user from blame or loss in
   almost any circumstance but nevertheless manage to profitably
   transfer an average of over $500 billion every day [FedRes2016]
   [FedRes2016] .

   The Mesh does not impose a model for mapping human to machine
   interaction identifiers but it does allow the user to put that
   mapping under their personal control.  Devices connected to a Mesh
   Personal Profile share the same view of the world; the same set of
   bookmarks and contacts for defining personal names and the same set
   of trust roots for Certification Authorities trusted to provide
   brokered trust.

   In the existing model, mapping of the address https://example.com/ to
   a secure TLS endpoint takes place in two stages.  First the DNS
   infrastructure is used to resolve the address example.com to an IP
   address.  Next, the client begins making a connection to the host at
   the specified IP address, receives and validates a PKIX trust chain
   to a recognized authority and if satisfactory, declares the TLS
   connection trusted:

   [[This figure is not viewable in this format.  The figure is
   available at http://prismproof.org/Documents/draft-hallambaker-mesh-
   naming.html.]]


   Traditional Internet discovery

   This approach is serviceable for the intended purpose of the WebPKI:
   Authenticating the Web sites that the user interacts with.  It is
   less satisfactory as the basis for establishing connections in the
   Hollywood Alice scenario.

   One of the biggest problems with the traditional approach is that TLS
   is only used to authenticate the server to the client.  The user



Hallam-Baker            Expires February 13, 2018              [Page 10]

Internet-Draft          Mathematical Mesh Naming             August 2017


   experience for client certificates remains unacceptable leaving
   usernames and passwords as the only available credentialing
   mechanism.

   Consider the role of the camera in the Hollywood Alice scenario.
   Alice uses the camera to take pictures but this is only one of four
   interactions involving the camera.  If we are to achieve the
   Hollywood Alice user experience, these other three interactions must
   take place without any intervention by Alice.  But this is impossible
   if Alice is required to constantly enter passwords.

   [[This figure is not viewable in this format.  The figure is
   available at http://prismproof.org/Documents/draft-hallambaker-mesh-
   naming.html.]]


   Information flows involving Alice's DLSR

   Another limitation of this approach is that the naming role of the
   Certificate Authority is limited to validating DNS names.  This is a
   major constraint if our goal is moving beyond use of DNS for naming.

   To achieve a satisfactory user experience, we need to reverse the
   order of operations.  We make use of trusted authorities when mapping
   the human interaction identifier to a machine interaction identifier
   whose interpretation does not depend on a trusted authority.

   [[This figure is not viewable in this format.  The figure is
   available at http://prismproof.org/Documents/draft-hallambaker-mesh-
   naming.html.]]


   Use as Trusted Authorities as Introducers.

   The most important trusted authority for Alice is of course, Alice
   herself.  While a typical Web user may visit hundreds or even
   thousands of different Web sites in a month, they will only buy from
   a rather smaller number and will in most cases use one or two
   financial institutions.

   When Alice opens an account with a new financial institution, she
   adds them to her personal contact directory and (optionally) gives
   them a shortcut name.  In the process, she reviews the credentials
   presented by the bank, a WebPKI Extended Validation certificate with
   a logotype extension presenting the Bank trademark.  From the point
   at which the financial institution is added to Alice?s personal
   contact directory, the role of the Trust Authority is limited to
   revoking the trust relationship should the need arise.



Hallam-Baker            Expires February 13, 2018              [Page 11]

Internet-Draft          Mathematical Mesh Naming             August 2017


   If this approach is to work, we need a new type of Machine
   Interpretation Identifier, one that can express both the network
   addressing and the trust relationship to the network endpoint.
   Strong Internet Names are one possible approach towards that goal.

3.  Strong Internet Names

   A Strong Internet Name (SIN) is a name containing a DNS label that is
   cryptographically bound to a security policy government the
   interpretation of the name.

   The use of fingerprints of cryptographic keys to establish was
   introduced in PGP.  PGP fingerprints provide a secure means of
   authenticating the public key(s) of an email user but at the cost of
   introducing a second identifier for each user that senders must
   manage in addition to their email address.  Like many issues in
   computing, this is a simple matter until faced with application
   software that does not support it.

   Use of a SIN DNS label permits these two pieces of information to be
   combined in a single identifier that is compliant with existing
   application software by employing the DNS prefix approach introduced
   by punycode [RFC3492] [RFC3492] . It is established that DNS names of
   the form xx--<data> (where x is any alphabetic character) are
   reserved.  A SIN DNS label has the form mm--<UDF-of-policy> where
   <UDF-of-policy> is the Uniform Data Fingerprint (UDF) of the
   controlling security policy as described in the following section.

3.1.  UDF Fingerprint

   The Uniform Data Fingerprint (UDF) format [draft-hallambaker-udf]
   [draft-hallambaker-udf] 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 [RFC6920] [RFC6920] . 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

                                 Figure 1

   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.






Hallam-Baker            Expires February 13, 2018              [Page 12]

Internet-Draft          Mathematical Mesh Naming             August 2017


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

                                 Figure 2

   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.

   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.

3.2.  Strong Email Addresses

   A Strong Email Address is an RFC822 compliant email address in which
   the DNS address part is a SIN bound to a security policy that is
   relevant to email.  For example:

      An S/MIME certificate to be used for encryption and/or signature
      as specified by the certificate keyUsage extensions.

      A root or intermediary certificate under which end user S/MIME
      certificates must be validated.

      A comprehensive security policy description language that allows
      the user to specify the use of S/MIME and OpenPGP keys for
      encryption and signature and the context in which they are to be
      used.  An example of a possible messaging security policy is
      described below.

   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:

      A regular email address (not a SIN).




Hallam-Baker            Expires February 13, 2018              [Page 13]

Internet-Draft          Mathematical Mesh Naming             August 2017


      A strong email address that is backwards compatible.

      A strong email address that is backwards incompatible.

   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:

      Send mail to Alice without requiring security enhancements.

      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.

      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.3.  Network Administration

   Strong names may also be used for network configuration.  Example
   Inc. might enable users to force users to make use of a SIN-aware
   email client by configuring the SRV records for the inbound and
   outbound mail servers as follows:

   $origin example.com.
   _imap._tcp     SRV 0 1 995 \
              imap.example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.
   _submit._tcp   SRV 0 1 465 \
              smtp.example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.

                                 Figure 3

   Since the fingerprint mb2gk- is of a PKIX certificate signing
   certificate, the requirement to use TLS is explicit.  This could be
   specified explicitly by means of a prefixed TXT record as described
   in [RFC6763] [RFC6763] .




Hallam-Baker            Expires February 13, 2018              [Page 14]

Internet-Draft          Mathematical Mesh Naming             August 2017


   For example, Alice is a user of the EXAMPLE service, a version
   management system used at Example Inc. This is a Web Service
   described by an SRV record as follows:

   $origin example.com
   _example._tcp  TXT \
              "tls=mb2gk-6duf5-ygyyl-jny5e-rwshz;min=1.2;max=1.3"
   _example._tcp  SRV 0 1 443 host1.example.com
   _example._tcp  SRV 0 1 443 host2.example.com
   _example._tcp.host1 TXT \
              "quic=mm--mb2gk-6duf5-ygyyl-jny5e-rwshz v=2.3"

                                 Figure 4

   Since the UDF fingerprint is used here as a parameter rather than as
   an embedded part of a DNS name, the mm-- prefix is unnecessary and
   can be omitted.  Though it is probably good manners for applications
   to tolerate its occurrence in cases where it is unnecessary such as
   the second TXT record.

   In this example, there are two separate TXT records describing the
   EXAMPLE service.  The first record applies to all hosts that provide
   the EXAMPLE service and specifies a PKIX intermediary certificate
   under which the TLS certificate MUST validate if it is to be
   accepted.  The second TXT record applies only to host1 and contains
   additional information specific to that host.  In this case host1
   offers the quic protocol but host2 does not.

   It will be noted that this capability allows similar capabilities to
   the security policy capabilities provided by TLSA records [RFC6698]
   [RFC6698] , but in a form that is directly integrated into SRV
   discovery and offers greater flexibility.  A Security Policy
   specified in a TXT record is not limited to the TLS protocol or even
   to TLS based key exchanges.  The discovery mechanism described in
   [RFC6763] [RFC6763] has proven utility and is widely used.  It is
   surely time to recognize this fact and back the winner rather than
   continuing to ignore it for the sake of a favored son.

   The previous examples demonstrated the use of SINs to perform high
   level, site wide administration tasks.  But the security policy
   specified in a SIN need not be limited to defining a site wide global
   root of trust.  The following configuration file is used in a
   robotics project to authenticate command signals between the central
   controller and various control outputs:







Hallam-Baker            Expires February 13, 2018              [Page 15]

Internet-Draft          Mathematical Mesh Naming             August 2017


   Plunger:      mm--maxxc-2lxmf-2xs4t-foq5w-63djo.local
   Exterminator: mm--mcf3x-kzlsh-n2g6z-3iof3-tw43m.local
   Dome:         mm--mdn5z-gkz3i-hnqwy-23tnn-sgqzz.local
   Lights :      mm--ma3nn-wgc43-i3mnn-qwq43-enm5w.local

                                 Figure 5

   Specifying the computer systems controlling the appendages connected
   to the robot in this way permits all communications to be protected
   using strong encryption while ensuring that the system can continue
   to function even if it is impossible to validate the trust paths with
   respect to an external root of trust.

3.4.  Security Policy Specification

   The UDF format used to construct SINs is calculated over both the
   content data and the IANA content type.  This allows the use of SINs
   to bind an identify to a security policy described in any language
   whether currently existing or to be defined in the future.  A
   security policy specification may be explicit or implicit.

   If a security policy is a PKIX Certificate Signing Certificate or
   End-Entity Certificate, the use of a security protocol consistent
   with the certificate attributes and protocol is required.  This
   approach allows the use of SINs to require the use of an appropriate
   security protocol with specified credentials in a wide variety of
   legacy application protocols.

   Implicit security policy is convenient but blunt tool.  We can
   establish a baseline for security in the case that an email address
   SIN authenticates a PKIX end-entity certificate with the
   dataEncipherment key usage set (i.e. use of S/MIME encryption is
   required).  But once that baseline security is defined, we can only
   improve on it by decorating the certificate with additional
   extensions to specify security policy.  This approach is unlikely to
   be satisfactory in the long term.

   The introduction of an expressive security policy language defined in
   an appropriate encoding (e.g.  YAML, JSON, XML) offers much more
   interesting possibilities.  For example, we would like an enterprise
   level security policy to allow specification of security policy
   parameters such as:

   o  The default DNS zone

   o  The UDF of the DNSSEC zone signing key

   o  The UDF of the PKIX enterprise CA



Hallam-Baker            Expires February 13, 2018              [Page 16]

Internet-Draft          Mathematical Mesh Naming             August 2017


   o  The network directory protocols supported (e.g.  LDAP)

   o  The authentication requirements for external network access

   o  IPSEC profile

   At the user level, a security policy would describe the communication
   identifiers and protocols by which the person could be contacted.  It
   is quite likely that these would be different depending on who is
   trying to contact them.  End-to-end encryption is not an unqualified
   benefit when it provides an attacker with a channel for bypassing
   filtering for spam and malware.  Thus, a user level security policy
   is likely to require conditional clauses:

      Must sign their email messages with public key enrolled in a Mesh
      notary log

      You may send me encrypted messages of any type, including
      executable code

      You may send me encrypted messages but not executable code

      You may send me an encrypted contact request message containing no
      more than 4K of text characters

      Here is the public key of my spam filter.

   While such rules are complex, it is complexity that a user would only
   ever encounter if they were trying to send a message that violated
   the rules.

   As with any configuration language, the specification of a security
   policy language requires a balance to be struck between simplicity
   and expressiveness.  Discovering the optimal balance is a task left
   to future work.

3.5.  Resolving SINs

   A SIN provides a mechanism for binding an Internet address to a means
   of authenticating a security policy under which the name is to be
   interpreted but does not necessarily provide a means for discovering
   security policies.

   This omission is intentional as there are many circumstances in which
   we would want authorized parties to apply a security policy without
   disclosing the security policy to unauthorized parties.  A security
   policy must inevitably disclose information that might interest an




Hallam-Baker            Expires February 13, 2018              [Page 17]

Internet-Draft          Mathematical Mesh Naming             August 2017


   attacker and so it is information that we should not disclose to
   parties without a need to know.

   When a synchronous protocol such as VOIP or chat is used, the
   security policy governing a SIN may be disclosed in-band during the
   protocol exchange in which the underlying DNS name is used.  This
   approach does not work as well for asynchronous protocols such as
   email or for network administration.

   The Mathematical Mesh provides one possible infrastructure that might
   be used to resolve SINs to the corresponding security policy, and
   using a linked notary log approach (aka Blockchain), a mechanism for
   publishing updates securely.  It is not the only infrastructure that
   might be used, nor is it likely to be the best for every application.
   For example, a new machine connecting to an enterprise network for
   the first time might obtain its initial security policy through a DNS
   CERT record [RFC4398] [RFC4398] .

4.  Personal Mesh

   To complete the explanation of how to realize the Hollywood Alice
   scenario in practice, we turn to a brief overview of the Mesh itself.
   At the simplest level, the Mesh is simply a tool that allows a user
   to bind all their disparate electronic devices into one logical unit
   by means of cryptographic credentials that are in normal
   circumstances hidden from the user?s view.

   To begin using the Mesh, Alice first creates a personal profile and
   registers it to a CryptoMesh portal.  Alice?s personal profile
   contains a master profile containing a set of administrative keys
   that are used to sign updates to the personal profile and master
   signature key that is used to sign the master profile itself.  The
   fingerprint of the master signature key is the user?s personal mesh
   fingerprint.

   meshman /personal alice@prismproof.org "Alice Example"
   Fingerprint: MCCW5-PYAX5-ZJ2TU-BVYT6-5Z3E6-DYA3I

                                 Figure 6

   A real-life Hollywood Alice would probably use an app on her
   smartphone for this purpose.  For this paper, the command line tool
   to illustrate examples is more convenient.

   The Cryptomesh is envisaged as an open co-operative infrastructure
   for management of public Mesh profiles.  The CryptoMesh cannot suffer
   a confidentiality breach as all the data submitted to or created by
   the CryptoMesh is public.  End-to-end confidentiality of private



Hallam-Baker            Expires February 13, 2018              [Page 18]

Internet-Draft          Mathematical Mesh Naming             August 2017


   components of personal profiles is achieved by use of strong
   cryptography.

   Use of the CryptoMesh provides the typical user with all the
   advantages of a cloud service without the usual disadvantage of being
   tied to a single cloud provider.  Users may change their Mesh portal
   at any time without notice.  All the information that is stored in
   the CryptoMesh is also stored on the user?s personal devices.

   A user is not even required to use the CryptoMesh at all.  Though any
   party who is security conscious enough to want to run their own
   private Mesh portal is likely to appreciate the fact that compromise
   of the private portal while undesirable will not result in a breach
   of the applications it is used to support.

4.1.  Connecting Devices

   Having created her personal profile on one of her devices, Alice?s
   next action is to connect more devices, her new DSLR camera for
   example.  To do this, she simply runs the Mesh administration tool on
   the new device and specifies the name of the profile to connect to.
   The tool fetches the personal profile from the portal and reports the
   UDF fingerprint for Alice to check, should she want to do so.

   meshman /connect alice@example.com
   Fingerprint: MCCW5-PYAX5-ZJ2TU-BVYT6-5Z3E6-DYA3I
   Code: VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX

                                 Figure 7

   To complete the process, Alice must confirm the connection request on
   the first device.  The manager provides a list of pending connection
   requests.

   meshman /pending
   Code: VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX
       Description: Nikon D850

                                 Figure 8

   Alice verifies that the connection request has the same comparison
   identifier.  This identifier is a fingerprint of Alice?s personal
   mesh fingerprint and the fingerprint of the new device profile.  Thus
   if the identifiers match, mutual authentication is achieved and Alice
   accepts the request:






Hallam-Baker            Expires February 13, 2018              [Page 19]

Internet-Draft          Mathematical Mesh Naming             August 2017


   meshman /accept VC25D
   Accepted VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX

                                 Figure 9

   Given an appropriately secured booking system, Alice?s hire car may
   be connected to her personal profile automatically but only for the
   limited purpose of receiving commands and preferences from Alice and
   her connected devices.  For the period of the rental, the hire car
   responds to Alice as its trusted user.

4.2.  Connecting Applications

   Having connected her devices, Alice begins connecting applications.
   Alice wants all the devices she has connected thus far to have secure
   email, SSH credential management and Web credential management:

   meshman /mail alice@example.com
   meshman /ssh
   meshman /web

                                 Figure 10

   The Mesh approach to usability is to ask as little of the user as
   possible.  Why bother to ask the user if they want S/MIME or OpenPGP
   credentials when it is as easy to provide both?

   Alice connects her cloud storage provider to her personal profile,
   thus enabling its use by any of her devices that require data
   storage.

4.3.  Contacts Directory

   Having briefly described the Mesh itself, we may describe the use of
   the Mesh to support naming infrastructures.  One such application is
   the use of a shared contacts directory across connected devices.
   This allows the user to create personal names or shortcuts for all
   the people and devices they might interact with.

   Alice has created shortcuts in her Mesh contacts directory for ?Bob?
   and ?Carol?. These shortcuts allowed her to establish the conference
   call with a voice command.

5.  Acknowledgements

   The ideas in this paper were developed over several years with the
   aid of Melih Abdulhayoglu, Robin Alden, Rob Stradling and Egemen Tas.




Hallam-Baker            Expires February 13, 2018              [Page 20]

Internet-Draft          Mathematical Mesh Naming             August 2017


6.  Security Considerations

   This document describes the use of identifiers in the Mathematical
   Mesh and the security concerns that this gives rise to.  The concepts
   of Expectations, Work Factor and Authority are explored.

6.1.  Expectations

   Whenever humans are required to interact with an identifier, their
   reasonable expectations must be met.  Rather too often, it is the
   protocol designer?s expectations of the user rather than the user?s
   expectations of the protocol that have been primary.

6.2.  Work Factor

   No security infrastructure is invulnerable.  Given infinite computing
   resources, even the strongest code can be broken.  What matters is
   how difficult the security infrastructure is to break.  When
   considering the strength of a cryptographic algorithm we consider the
   work factor measured in operations.  Work factors of 2128 or greater
   are generally considered to be prohibitively difficult to break if
   the algorithm is secure regardless of future computing advances.
   Work factors of 2256 or greater present a generous safety margin.

   Unfortunately, the cryptography used in a security system is rarely
   the weakest link.  Thus, when considering systems rather than
   algorithms, an estimate of cost (i.e. in dollars or other currency)
   is more informative.  The architecture of the WebPKI was originally
   developed using a work factor based on the estimated cost of
   obtaining a false credential and the expected criminal gain.
   Deterrence is achieved when the apparent cost is greater than the
   apparent gain.

   As noted in a previous paper [draft-hallambaker-prismproof-trust]
   [draft-hallambaker-prismproof-trust] , linked notary log technology
   (aka Blockchain) makes the cost of a backdating attack, near
   infinite.  This property may be used to advantage in developing a
   naming infrastructure.

6.3.  Authority

   The use of any identifier whose interpretation relies on the action
   of an external authority raises the problem of delegating trust.  The
   problem is the same whether the authority be a single entity (e.g.
   ICANN) or multiple entities (e.g.  WebPKI Certificate Authorities).

   Terms of debate which allow one type of authority to be attacked
   relentlessly while holding the other as unimpeachable are



Hallam-Baker            Expires February 13, 2018              [Page 21]

Internet-Draft          Mathematical Mesh Naming             August 2017


   unacceptable and must be discarded.  Any party that proposes to act
   as an authority in any form of naming scheme must accept that they
   are accountable to the community they serve.

   The approach described in this paper does not eliminate the authority
   problem but does allow it to be confined to the problem of mapping
   human interaction identifiers to other forms of identifier.  Secure
   Internet Names are identifiers that are bound to a specific security
   policy governing their interpretation, allowing the role of any
   authority to be absolutely circumscribed.

7.  IANA Considerations

   This document has no considerations for IANA.

8.  Informative References

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

   [draft-hallambaker-prismproof-trust]
              Hallam-Baker, P., "PRISM Proof Trust Model", draft-
              hallambaker-prismproof-trust-01 (work in progress),
              October 2014.

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

   [FedRes2016]
              Federal Reserve, "The Federal Reserve Payments Study
              2016", December 2016.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003.

   [RFC3709]  Santesson, S., Housley, R., and T. Freeman, "Internet
              X.509 Public Key Infrastructure: Logotypes in X.509
              Certificates", RFC 3709, DOI 10.17487/RFC3709, February
              2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005.




Hallam-Baker            Expires February 13, 2018              [Page 22]

Internet-Draft          Mathematical Mesh Naming             August 2017


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

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013.

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com































Hallam-Baker            Expires February 13, 2018              [Page 23]