22K/ Safe Internet Use with KERI: Percolated Discovery OOBIS and Spanning Trust Layer

Safe Internet Use With KERI: Percolated Discovery OOBIS & Spanning Trust Layer

Thursday 22K

Convener: Sam Smith

Notes-taker(s): Henk van Cann

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Session Presentation:

https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_Percolation_OOBI.web.pdf

Notes are an addition to the slides in chronological order.

PERCOLATION

You don’t need global lookup if you have invasion percolation.

Example: oil and water in a sponge, water will displace oil. We are talking about information flows. Metaphor: good information can drive out bad information. We are looking at authentic information. That’s what we care about.

Not the veracity, that’s a layer above KERI.

There are two controllers involved: the holder and the verifier. In KERI that means, controller of the key.
Two moments in time: issuance and presentation.

The issuer is responsible for the registry. What could be problematic is that the state of the registry has changed between issuance and presentation. But it is still possible to get it. Percolation is multiple path.

You can percolate information as well as the route; so the path doesn’t matter.

We do not need a global registry with shared control.

Definition ‘Information is…’ in KERI :

Good => verifiable authentic attribution

Bad => not end-verifiable

In KERI ‘Truth’ is authenticity not veracity (veracity is more ‘truthful, consistent’)
‘Spanning’ means available

By having percolation and end-verifiability our problem is not security but just availability. Sam: “I’d rather have an availability problem than I have a security problem”.
Security issue example: The most common attacks are (BGP) hijack attacks at certification authorities (middleman). They are complex and sophisticated nowadays.

Henk van Cann: KERI solves hijack attacks, because the binding between the controlling keypair (primary root-of-trust) and the identifier is strong, because it’s cryptographically end-verifiable.

Participant: How about privacy with percolation?
Sam: very good question. It’s being discussed in the PAC sessions (day 2 and day 3)

The discovery is not ‘search’, it’s by already known connections, peerwise, on a need-to-know basis.

There is no global non permissioned search allowed in KERI.

Sidebar: In privacy, “Need to know” typically means that the entity wanting to know has a privacy - valid basis for wanting the information. As opposed to ‘need to know’ information about you for my business model.

In KERI need-to-know has a security base, pairwise.

KERI sits on top of the internet. Therefore our endpoints are URLs
All roles / all players in KERI have AIDs.

Sam’s vision:

KERI needs to be minimally sufficient . Therefore it sometimes uses rather simple but reliable cryptography instead of the newest less tested stuff.

Analogy Henk van Cann: You could use and build spreadsheets with the newest and most complex functions or solve the issue with just *,/,+ en -. The former might impose maintenance and backwards compatibility problems on us, the latter does the job too.

Everything needs to be end-verifiable for trust, full stop. You can use it, but you can’t trust it if it’s not.

Pre-rotation and key management in KERI fixes a problem on the internet (verifiable attribution) that persists for 30 years.

From a security perspective Open ID connect (and OAuth and Fido2) are still subject to same attacks, it’s harder, but still possible. Because it’s not end-verifiable, conversely, KERI is.

KERI can’t get rid of the attack vector key management. All the other security problems we’ve solved that’s why we are trying to do key management as good as possible.

OOBI

Out of Band Introduction : https://hackmd.io/MxTAIBQTRkWU4-w140tNuA

A DHT is a welcome structure for availability in KERI, but it can’t be a crucial part of the security mechanism.

KERI can’t solve the problem of connecting a natural person to an identifier (primary root-of-trust). The good thing is: it only needs to be done once. After that everything is end-verifiable.