Re: [Secdispatch] Call for Agenda items

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 04 July 2019 20:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF79612016E for <secdispatch@ietfa.amsl.com>; Thu, 4 Jul 2019 13:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VunYeFXRlsL4 for <secdispatch@ietfa.amsl.com>; Thu, 4 Jul 2019 13:27:07 -0700 (PDT)
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 6C5A1120232 for <secdispatch@ietf.org>; Thu, 4 Jul 2019 13:27:07 -0700 (PDT)
Received: by mail-ot1-f44.google.com with SMTP id l15so6977574otn.9 for <secdispatch@ietf.org>; Thu, 04 Jul 2019 13:27:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z+TnrFrdkma9/ByZECtAVJSuNDaiPwsRgU4kaLJFqRQ=; b=pZ0ror5qWqpAlcwaxhYMHC1m8AevV+XPZJEQ/6bVEzBBRu5p7F4K398WKxMVdQwtpm JPPIcRXOnvBxooOhrVr/wBWwcEbKeof20dkbHmQs0ban9z0X5Hek7lx2UpVPZ6XY6eOK BLaKuQFyDfsvDkxPAvEPlLJyExbgjtT0trOXqTKSydoaEvFMiU07K6FGFS+5SLEs738h vzmaor6Ep6xU2om2y3W7P6p/0n+RG3aPd5gDwSTyEs7jMyVpAVcuzvRq+QIB1DSLXodV K1ecLtMItRQqj40RVN1/Zta3hG2iXG4PNxBg0mn4ebH8k1V3lnxRKvXMglOY1tryGJWi RFSA==
X-Gm-Message-State: APjAAAWlbGneVIlnSgYJgE+olTrVL71paLkjlJdv1weec/VHVgt2wM3H DTVeKkwe46CmjWi+oEaCAvX6I1xPpwu11YvJQec=
X-Google-Smtp-Source: APXvYqw3WJ2xyRdpsNFxpkj6A1VJHwTnhTV0XLN9vK4NOEcAUUvI0CW11Y786SEiEf55wXtzUYQYiwW/3Sab+HOLKuM=
X-Received: by 2002:a9d:7d02:: with SMTP id v2mr13594563otn.112.1562272026406; Thu, 04 Jul 2019 13:27:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbuEH7eHTdbAJsGJ0_A2pSEBFq-3nq8e+5Fqw_JaSaXTh=fTQ@mail.gmail.com>
In-Reply-To: <CAHbuEH7eHTdbAJsGJ0_A2pSEBFq-3nq8e+5Fqw_JaSaXTh=fTQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 4 Jul 2019 16:26:56 -0400
Message-ID: <CAMm+Lwj=SzQ-mTpsB-0Dh1Zp7p_=pzLz4OXTDtUg=H6X0fXhHQ@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002d3423058ce0cdf7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/eOl-klH_6YeRKw_YNg-ym6S4BRM>
Subject: Re: [Secdispatch] Call for Agenda items
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 20:27:10 -0000

I would like to present the Mathematical Mesh I have been working on. I
would also like to arrange to meet people who may be interested in this
work at a BAR BOF. Preferably one in an actual bar at this point.

Right now, the only person funding this work is me (though I am grateful
for the considerable amount of support from Comodo). I am currently looking
at options to take the work further. The one non-negotiable criteria being
that this is at root a communications system, it can only reach its full
potential if it is unencumbered, that means anyone can use it or extend it
without fees, licenses or permission.


The objective of the Mesh is to make computers easier to use by providing a
security infrastructure that works without users needing to be aware that
they are using it.

The Mesh can be used as a mechanism for managing credentials (passwords,
private keys, etc.) for existing security applications (SSH, OpenPGP,
S/MIME) or it can be used as a platform for developing new applications
(end-to-end secure password catalog, secure contact exchange).

One of my frustrations with the current situation in the industry is that
we haven't moved on from cryptography developed in the 1980s. We have
better algorithms to use in place of DES, MD5 and RSA but we haven't added
a new capability since BitCoin added hash chains to the canon ten years ago
and the patent on that was 1990.

The Mesh introduces a new set of cryptographic techniques:

*Uniform Data Fingerprints*: Think of this as 'Cryptography on rails'.
Rails is a powerful framework because it uses the same name for the same
field in every situation. UDF does the same for cryptographic keys.

*QR Codes*: Imagine being able to scan a QR code on your bills, your pay
stubs, tax advice, etc and get to a machine readable copy of the document
you are reading. That is what EARLs provide.

*Multi-Party Key Generation*: Weak keys have been a problem for decades and
now we have to consider the possibility that a key was compromised by the
device manufacturer. But keys generated during manufacture that cannot be
extracted could be the very best keys to use (if we can trust them).
Combining keys generated on multiple devices allows this concern to be
mitigated.

*Multi-Party Decryption*: Traditional CRM schemes use the Ford-Wiener key
release with a key server in the cloud dispensing decryption keys to
authorized readers. The problem with this approach is that our chief data
confidentiality concern is a breach of the cloud, i.e. the key server.
Separating the decryption function into two parts and requiring both to
participate enables a key server to control decryption of data without
being able to decrypt.

*DARE Envelope*: This is a new PKCS#7 type format built on JOSE which
provides the hooks needed to support the Multi-Party Decryption scheme DARE
Container.

*DARE Container*: An append only log format supporting incremental
encryption and authentication. If I am talking to VC, I might even call it
a block chain.

*Shamir Secret Sharing*: Personal Escrow of the user's keys is supported
with up to 16 shares and a quorum of 1-15.

There is quite a bit more to the system but it remains remarkably compact
and especially so considering the scope of its capabilities.

One innovation that addresses a current concern is that Mesh Accounts are
the property of a user and not the service provider. So if I want to change
my service provider from example.com to example.net, I can do that at any
time of my choosing and I don't need example.com to co-operate of give
permission for the transfer.

The trust model does have a role for Certificate Authorities but this is
optional and limited to the discovery process, CAs are not ongoing
participants in every transaction. Direct exchange is also supported via
both an in-person model (e.g. QR code exchange or bump phones) or remotely.


All the reference code is MIT License and copyright Comodo Group (to
Version 2.0) and Comodo Group and myself (3.0 on). The tool chain used to
build the system is MIT License and my copyright. I have attempted to avoid
encumbered technology and I am not aware of any valid claims on the current
specs but make no warranties in that regard.


I have submitted all the documents as Internet drafts but there is a catch,
I am writing the documents assuming that the transition to HTML RFCs is
going to happen. So you can read them as plaintext drafts if you insist.
But the HTML documents have diagrams and use superscripts and subscripts
for the math rather than X_A which makes them a lot easier to read.

The architecture draft provides an overview of the project:

http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

The following drafts are nearing completion. I am currently working on
getting the worked examples from the running code worked in:

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html
http://mathmesh.com/Docume…/draft-hallambaker-mesh-dare.html
http://mathmesh.com/Docu…/draft-hallambaker-mesh-schema.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html


I might have the protocol specification available by Montreal but that
might slip.



On Wed, Jun 26, 2019 at 2:55 PM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> Hello,
>
> If you wish to present at SecDispatch in Montreal, please send a message
> to the chairs and preferably to the list with the draft link that you plan
> to present.
>
> Thank you.
>
> --
>
> Best regards,
> Kathleen
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>