Subject: Re: [Secdispatch] Call for Agenda items

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Jul 2019 13:53:25 +0100

On 26/6/19 19:55, Kathleen Moriarty 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.

Not sure whether another presentation is needed... but we'd like to hear
thoughts on how to make progress on our draft on numeric IDs (or its
splited version).

If a presentation is needed, I could do a remote one.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Jul 2019 20:06:21 -0500

> thoughts on how to make progress on our draft on numeric IDs (or its

FWIW, if I remember correctly the history it would be reasonable for me to
AD-sponsor draft-gont-numeric-ids-sec-considerations, but I haven't had a
chance to double-check my memory yet.

> If a presentation is needed, I could do a remote one.

I'd love to hear feedback from people about
draft-gont-numeric-ids-sec-considerations even before Montreal; it's not
really clear to me yet whether a presentation is needed, either.

-Ben

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Jul 2019 16:26:56 -0400

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 <
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 8 Jul 2019 14:07:52 -0400

Thanks, Phil.

Please feel free to comment on Phil's proposal and drafts in a new thread.

Best regards,
Kathleen

On Thu, Jul 4, 2019 at 4:27 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> 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.
>
> *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).
> 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.

-- 

Best regards,
Kathleen