Subject: [DNSOP] Request for guidance on SIN

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Mar 2018 12:45:30 -0400

Strong Internet Names is a concept that I have been developing for about 4
years now. It is an extension of concepts that Brian LaMachia and team
applied to the design of dotNET security with great success and I think it
has value applied at the network level.

The current draft can be found in HTML format here:
http://mathmesh.com/Documents/draft-hallambaker-sin.html

The related draft describing UDFs can be found here:
http://mathmesh.com/Documents/draft-hallambaker-udf.html

The question I would like to pose is which group to raise the work in as it
is a security specification with DNS implications.

This is one of the technologies I am using to build the mathematical mesh
but it is not limited to that application. The relationship is similar to
that of URIs to HTTP, they are both used in the Web but URIs are much wider
in scope.

The basic concept of a SIN is to bind together an Internet address and a
security policy that constrains the interpretation and use of that address.

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.
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-2>

Alice is an employee of Example Inc., she uses three email addresses:
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-3>
[email-masked]
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-4>A regular
email address (not a SIN).
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-5>
[email-masked]
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-6>A strong
email address that is backwards compatible.
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-7>
[email-masked]
<http://mathmesh.com/Documents/draft-hallambaker-sin.html#s-3-8>A strong
email address that is backwards incompatible. These are addresses that can
be entered into the contacts directory of any existing email client. Note
the use of the mm-- prefix to identify this as a SIN. Existing policy means
these labels cannot be issued as ICANN TLDs etc. That coupled with the fact
that accidental collisions are statistically improbable and these names are
as robust as is possible.

Putting what is functionally a superset of an OpenPGP fingerprint into a
domain name means that we can cryptographically harden any system.

This is not necessarily a construct that would be put in front of a user,
most of the time we use SINs in the mesh it is to record the outcome of a
trust decision.

So in the example above, Alice might give me her business card, I send her
an email and when she replies, there is a header giving me her Strong email
address which is bound to a security policy such as 'always use end-to-end
encryption with either S/MIME or OpenPGP and here are my keys'.

Certificate Authorities are currently employed as trust providers. In the
SIN model, we can limit their role to that of Trusted Introducers who are
only required to make the initial connection.

There is of course an infinite amount of complexity in the specification
and application of security policies. And the design of UDFs takes account
of that with a construction that provides for isolation of semantic domains.

What I want to do at this point is to get the foundations laid to allow us
to build interesting stuff. The interesting stuff itself is a separate
matter.