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 (,) 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."