Minutes IETF106: mathmesh
minutes-106-mathmesh-00

Mathematical Mesh BOF
18 nov 2019

Administrivia ...
-----------------


Overview
--------

The objective is to make computers easier to use by making
them more secure.  Cryptographically connect every device
Alice owns to each other - personal mesh.  Enable use of
strong end-to-end encryption.

Three core problems:
. provision private keys to all devices
. provide the means to obtain and validate private keys
. secure data at rest

Today we have siloed applications & separate configurations,
security falls between the cracks.

Mesh Core depends on UDF (naming infrastructure), DARE
(cryptographic envelopes), and Meta-Cryptography (new crypto
primitives).  Mesh Core provides narrow waist in the Mesh
architecture.

Proposing that for phase 1, pick one or two applications,
provide proof of concept.  Proposes focus on passwords.

Mesh password catalog provides 90% coverage of mesh
functionality.  Does not rely on network effect, addresses
fnctional password problem.  An open standard for a password
vault.

Make Alice her own root of trust.  She creates a personal
Mesh profikle.  Master signature key, administration keys.
Installs app on her mobile phone, add more devices by
scanning QR code, or installing an app and requesting
connection.

Every connected device has the same world view.  Every
connected device can authenticate messages of being "of
Alice"

Mesh components
. Mesh schema
. Mesh account
. Mesh service

EKR: how does this connect to password vault?  PHB: if this
is on one machine, stored locally.  If you've got 20
machines, password change is replicated across all machines
w/o centralized password vault.

Dino:  how to manage passwords for web-based services?  PHB:
as many passwords as you want

Michael Richardson:  How does this stop a thief who has your
phone from getting your passwords?  You can tell the service
not to provide decryption keys.  If thief gets there first
there's nothing you can do.  Q: can I do selective password
sharing?  A: yes

UDF
---

base-32 encoding of cryptographic data (digests, MACs,
symmetric keys, etc.).  All Mesh key-ids are Content-Digest
UDFs.


DARE (data at rest envelope)
----------------------------

Blockchain in JSON.  PKCS#7 for JSON Signature and
Encryption.  Mesh uses standard encryption, signature and
verification.  Uses KDF (<master secret>,<nonce>) to derive
IV and encryption, MAC key (if needed), signature witness
value.

Append-only log format (uses Merkle tree) provides
incremental authentication, incremental encryption.  Can
support an archive format.

DARE catalog - persistence store based on DARE sequence.

Dino:  do you think the Mesh service is decentralized?  A:
yes

Meta-Cryptography
-----------------

rebranding threshold crypto, etc.

Key combination:
    Private key X -> Public key X = x.P
    Private Key Y -> Public key Y - y.P
    Private Key z = x + y -> z = (x + y).P = X + Y

Can do away with proof-of-possession as a result.

Key splitting

Snowden-proof key management:  Cloud service can control
decryption but cannot decrypt.  Cloud only knows a random
number that can be generated without knowledge of private
key.

Stephen:  it's unclear to me that what you're presenting
stays as simple as it is without turning into something as
complicated as MLS.

Jeffrey Yasskin: how are you handling trust - information is
hidden from service but it's being trusted to manage users?
A: separation of duties can be applied.  Ben:  the starting
premise is that we want something that is easy to use, and
that can impact security constraints


Discussion
----------

Erik Nordmark:  can we do this for devices that don't have
user interfaces?

Roman: Is the focus on solving the password problem, or is
the password problem a use case for a broader effort.  PHB:
would prefer the latter

Roman: I struggle with how to measure success for the
broader effort

Michael Richardson:  I am with Phill in that I would like to
solve password problem as a step along the way for the
broader problem

Ben:  with no hat, I'm pretty excited about working on the
broader technology questions.

EKR: there are quite a few people already doing password
sync.  Which companies would use this?  Wes: something that
would come out of this would be interoperable password
management.

Laurence Lundblade: substantial overlap with work being done
in the FIDO Alliance

Ben Kaduk:  There are other potential use cases in addition
to password management/sync.

Erik:  I would apply pieces of this to IoT or edge
computing.

Alex: this seems related to decentralized identity work at
the W3C.  The main goal of this work is to get rid of
passwords.

Wes:  you're not actually getting rid of passwords, right?
It's a password storage system?  PHB:  you're using keys, so
you're moving away from passwords but not getting rid of
them entirely

Ben:  isn't this a key sync protocol rather than a password
sync protocol?  PHB:  yes

David Schinazi: this feels like a grand unified theory of
cryptography, a way to tie a lot of things together.  This
is not what the IETF does well.  The IETF solves specific
problems.  So, pick a use case.  This is currently way too
vague to be tractable.

EKR: David said the things I'd have said.  Is there a user
community that wants that box solved?  Let's find a customer
for this who's excited about it?

Michael:  echoes EKR.  Gave example of management of bearer
tokens

Chris Wood:  As an operating system vendor, we would not be
interested in interoperable any of this

Wes:  There's a fair amount of resistance to the password
problem, but there is interest in other pieces.  Roman:  we
didn't dive into any of the blue boxes individually.

Michael:  UDF provides a way to pass certificates by
reference rather than by value.  Wants to reiterate IoT
backup/restore problem has no solution currently.

Ben:  Does Michael think there are people in the room or in
IETF who'd be interested in using this?  Michael:  There are
people in the room working for those companies, although the
people present aren't working on those products

Jonathan Hamil:  I don't see a path to quantum resistance?
My main concern is that by the time this is deployed it
won't be secure.  PHB: doesn't think we're close to having
actual quantum computers.  Escape hole would be based on
Kerberos or Lamport hash signatures.

Richard Barnes:  Cisco is working on IoT but this doesn't
map well to what Cisco is doing.

Ben:  you've summarized correctly what we've heard in the
room.  There's potential here but not a lot of interest in
the room in specific use cases.  Would like to suggest
there's potential in the blue boxes.  Will take hums

EKR:  we really didn't have much discussion of the merits of
these pieces of work

Ben:  asked who read individual documents?  About 10 in each
case

David:  process question - there's no problem statement for
the blue boxes.  Ben:  That's a fair point.

Michael:  We're allowed to have a second BOF, and maybe
you're asking your questions prematurely.  Should we ask if
there should be a second BOF?

Wes:  Can I rephrase this as a more positive point?  Do
people believe there are problem spaces that these
technologies might be relevant to

Martin Thomson:  is there a constituency for this work in
the IETF?

Roman:  we didn't find a constituency for any of the orange
boxes, but what about blue?

Ben: Is there any technology here that anybody would like to
know more about?

Roman:  Given the small number of people who've read the
documents, based on the discussion so far there's interest
in reading the documents and finding out more?  Hum resulted
in "yes."