[DNSOP] Request for guidance on SIN

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 29 March 2018 16:45 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CB7B012E044; Thu, 29 Mar 2018 09:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GIxH2NeJiHZN; Thu, 29 Mar 2018 09:45:32 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A5212420B; Thu, 29 Mar 2018 09:45:31 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id e8-v6so5723565oii.4; Thu, 29 Mar 2018 09:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=n2jEbCixnUbo5RYP2TxSJUD4d0mZgYNuPNTn1qcphBg=; b=K6nnmxdCQ9kEh2+hXo1hxPZcbVJKh0romqQvLuCf9SCTxW+vBw+k/Z3xAiLDS+JKIf DU7amunwHDjc3lallGX/FDQgTfkHhH7GWtkMj9QbUzf8wBDZSpvNnLc3vJ96P8qw7lum b57+81/swk0Xlx6micATVZ1Es8M4It3QgRTtrIEfJzAHexBuuv6oMhNujnx1qR6kAnt6 z5PV8QZK0RxP7/NX7FfENxKaweaezGHkE6vs75oyqXlyCPE2/V8rcBwFKghQbSyHNpxy m12I0xz8Rf1j1U3WVw3a5X4fYfu984ma1c3HLUMPiARu02DafQyJph50CM1S0uCRjMuV RbcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=n2jEbCixnUbo5RYP2TxSJUD4d0mZgYNuPNTn1qcphBg=; b=AMStZwCZkkjGv/QvStDezaXgZcTAA9s70apBq+beWZ48OrIvtWqb2iGX2HNuD/MNLg WgemLTdodLuYTZsmpK3ytIs6StbSrC8rpoN9kqG6+8iUhavSgO0IHbPKVBEVlMQVZ4wG P1TwZJTBIZ6FutZnTjOoq8uzdXxvqqZvCuBlxhNDfRYzowA+vJ1QK2LiSUWPXelPbyoj iq/P3Y4jSrHDb3JGOxdKt3I5h85CflQt0mg+lG0qFl2ngwX1K+b9+V/KIbGl/Ld8pxDj 5PaFbDuPxR8ECzJJxEUf+eHnX06OgdFv7gbAl+AKjRdZvGVKCfSiUqzrn+hijtcYy33D GXqQ==
X-Gm-Message-State: ALQs6tB5WiOq3MzrwqEfMKKr2yGhG0BivD9Qq/rv/SCzwKoVA9axCkyk 9VKQIhBdNX0rjikEwrdisWEtWk90Jg6xQbG4faMIuw==
X-Google-Smtp-Source: AIpwx491/s9HdFzFLkvJMRIjMQpd8Gy0R6zQwfWuOsNrEu48TBOxhOBUlY6fH9MwNej36hc9ILHoGCFNt4AblNjjKGI=
X-Received: by with SMTP id r198mr5118714oie.180.1522341930595; Thu, 29 Mar 2018 09:45:30 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 09:45:30 -0700 (PDT)
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 29 Mar 2018 12:45:30 -0400
X-Google-Sender-Auth: oiFKc_f7LgGyK2r7wn_6E-huAVs
Message-ID: <CAMm+LwirCgM1jGvXK5r9u782cvRDmd5n3gPOr2xiHfJX_uL0NA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>, secdispatch@ietf.org
Content-Type: multipart/alternative; boundary="001a113cd5e00002e405688fdad3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bQ9WueBeiUe8853WOPIxS0MAI4Y>
Subject: [DNSOP] Request for guidance on SIN
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2018 16:45:36 -0000

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:

The related draft describing UDFs can be found here:

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.

Alice is an employee of Example Inc., she uses three email addresses:
<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-6>A strong
email address that is backwards compatible.
<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