OCapN Pre-standardization Group

February 2024

Minutes

jar: No closed pull requests since last time. Floor is yours, Kris Kowal.

kris: Someone proposed to add tcp netlayer for the test suite, which inspired me to take the locators proposal and bolt on protocol negotiation that attempts to separate concerns. The sturdyref portion only contains the nonce and should be treated as equivalent to other references with the same nonce. We could add cryptographic hints that strattle multiple transport protocols. Currently, locators assume Tor. My proposal has transport-agnostic nonces. I have placed this on the "proverbial conference table" for discussion.

jar: I'm not clear on what the discussion is.

kris: PR 105 I'd like to open this to conversation.

jessica: I think it's interesting, and Spritely appreciates it. The proposal touches on something we've wanted to address, which is multiple ways of connecting to the same machine in one locator. This addresses it in a more explicit way. We took a look, but haven't submitted feedback on the PR. Many points here:

jessica: The first thing is that it seems it would be difficult to know, based on a locator, if you have a connection to a given machine already. Did I miss this?

kris: You might be right and there might a layer of indirection necessary. Each nonce can exist only on one node and presumably an adequate key for connecting to a node. That's the direction we're headed in with the pet daemon. Using the nonce as the key may not be adequate.

jessica: Is the nonce the identifier?

kris: Yes. I think it is compatible with the proposal to have another key on the reference that identifies the host separately from the object nonce. That wouldn't come at the expense of what I think is important: That transport details are not in the reference portion.

christine: What Jessica said captured some of our confusion. E had separate identifiers for vat/node and objects. If Alice and Alfred were both on the same node A, and this looked hinted towards in your PR... If you already had a reference to Alice and were given a reference to Alfred, if we're doing bidirectional session and we want shortening to work, how do you know if you are connecting to the same machine or an existing one? Having a separation between the node id and the object id makes this distinction possible. Bidirectional connections make this challenging, but we want to be certain whether we are reusing a connection or not. Mark talked about robust routing, multiple paths to reach the same node. There are security concerns around this. Assuming we didn't have those challenges, I found it strange that the writeup didn't make a distinction between object and node. Do you believe, in the current writeup, that we could detect that we already have a connection to Alice and can reuse it for Alfred?

kris: I think we need another iteration of the document that separates the object referenced from the node referenced. Locators has this and I missed it in mine. To turn the table around, do you think the locators proposal, as written, accounts for multiple routes?

christine: We were planning on adding something that uses composition. We don't currently have anything that does multi-route, though. Multiple routes to the same node is very compelling, but as I said I think there are some security issues. Jessica and I mocked up, but didn't have publicly, was a new netlayer type called "multi" that had a public key for the multi-adddress and could sign off on multiple paths to get to it. It's a meta layer. It would be another layer of composition, rather than fundamental, so we don't have to solve the security issues in the base protocol. Jessica was pushing for having multiple paths, but when I brought up the security issues she became less certain.

mark: Is this video what you had in mind?

https://www.youtube.com/watch?v=a0Wr2BvIixk&list=PLzDw4TTug5O0CTk1yiTb1b7-yTMTpoo0i

christine: Yes. Relative routing.

mark: Let me admit and apologize for not having read the current locator proposals. I don't have enough background to understand how the old concepts have been refactored into new concepts and what the new terminology is. But I'll ask the questions that I think always need to be answered. First of all, the old E system started with swissnums as the fundamental object authorization and moved away from that as being primary to clists. There are two party clists were each connection maintains a set of tables for the other side. For 3 party handoffs, there are handoff tables which are an adaptation of the clist idea but the particulars are quite different. I have a video that goes into it in some depth. The relative routing video covers it, too. The remaining place where swissnums were fundamental were for going from an offline reference, a captp uri string (not a sturdyref), which was intended to be something that had the security properties of a capability but could be transported over offline media (QR code, etc.). Those things, crucially, had 3 parts to it. With offline capabilities, that's where online capability has to be bootstrapped from, and in a way that preserves the security properties that the various parties agree on for the offline system, security shouldn't be weakened. The unguessable id had to be asymmetric .... (missed explanation). The swissnum is assumed to be an unguessbale secret, which is symmetrical, and you can only afford to do symmetrical when aligned with the underlying asymmetric authenticity. Relied on by itself, it doesn't distinguish between the ability to be the object and invoking the object. The designator had to couple the host id and the object id. The object id needed to stay secret and is not revealed to the alleged host until there's an end-to-end encrypted session, such as TLS. The third part is the routing hints. We called them hints because the security only depends on finding a counterparty, somehow, that can authenticate to the vat id that you possess. The web uses a single host IP or domain, we're not doing that, so the authenticated host could be reached through multiple paths or be mobile. The routing hint would have multiple places to get started in the query to find the host. The originator, the party that's trying to connect, could do a breadth-first search starting from the locations in the hints. The security issue that Christine mentioned is denial of routing. If there's only place to begin your search, that place could deny you access. Most of the solutions we've seen have too-centralized a notion of where your initial search starts. The idea here is that when you configure a vat, you can give it some places to start in addition to whatever comes in with the location hints. The vat of origin could say "if you want to find me, here are some places I recommend!" So, those are the 3 parts of offline capability. Blockchain causes us to substantially revisit what a vat id is. For proof of stake chains, the vat id cannot be assumed to valid for all time. Even without blockchain, for example key rotation, a stale old key should be viewed with suspicion. I think I've covered the fundamentals that need to be present in any system.

kris: This is great feedback overall. I want to address the non-blockchain feedback. I can see that my proposal isn't adequate and needs another iteration. As Christine mentioned, the "metlayer" (meta netlayer) is roughly analogous to what Mark describes as a QR code on the side of the bus. The thing that needs to change about my proposal is that we need to separate the vat id from the swissnum, which I think is very achievable. The bikeshed territory is the order. I think the vat id goes first and the swissnum second. The vat id would be the public key of the vat you want to connect to. It introduces a challenge to multi-homing. For vats inside a web page, you will be limited on ways to connect. There is a potential to conflate and couple the TLS mechanism vs. Tor vs. whatever else. Depending on what kind of connection you will be using, you will probably use different cryptography for each. We might an encryption method that works across all netlayers for the vat id so that the vat id isn't coupled to the transport. Transport-agnostic cryptography that corresponds to the vat id. To address denial of routing, my assumption was that it was a non-issue because the client is at liberty to try multiple means of connecting to a host and can race to see who connects first and close the other ones. Whoever authenticates first wins. That's all I have to say on this. Big points: Transport-agnostic crypto, and parallel connection attempts that race and one wins.

christine: We have more feedback that we should try to get through. Mark, what you said is what I expected. Everything you've raised are considerations we had in mind when we wrote the original ocapn uri spec. I was happy to see Kris' proposal because it's an opportunity to address confusion. For denial of routing, it's not adequate to race to connect. If Mallet attaches a route that looks viable to for Alice to connect to Bob. Alice connects through Mallet successfully, unknowingly, but then Mallet restricts traffic flow or monitors the traffic. This is where we thought "this is complicated" and we wanted to approach this through a composition strategy so that we don't have to solve these hard problems immediately but can experiment with solutions.

jessica: That covers the concerns regarding the security of multiple routes. The other feedback we have is:

jar: I wanted to allocate the last few minutes to figure out how we want to proceed from here.

kris: On behalf of Agoric and Endo. Metamask is funding a team to work on the pet daemon. We meet weekly on Wednesdays and that is a good venue to riff on this. 10am pacific. This would be a welcome topic. We don't have anything "in ink", though we are going to start working off the master branch in the endo repo very soon.

jar: Are you planning on revising the document in the next month?

kris: I intend to revise it to address vat identification via public key and attempt to figure out which crypto to use.

jar: This seems critical to concrete interop.

kris: Christine, I received the video of the meeting you missed and will post that today.

jar: What do we do with the last 7 minutes?

mark: I can give some updates. We've merged the "compact ordered" pseudo-binary format. I've got PRs for implementing the restriction of "strings have to be well-formed to be considered passable". Haven't merged yet, we are checking performance. I also have a PR that changes string ordering from utf16 code ordering to proper unicode codepoint ordering which is invariant over whether the underlying implementation is utf8, utf16, or whatever. That one is more painful in regard to what it is waiting on because there are places where we store things in string-sorted order. We don't have any ability to scan our chain to see if we have persisted strings that violate the order we want to move to. I'm not sure how to proceed on that.

jar: 4 minutes. Does Jessica or Christine want to give an update?

christine: I missed the last endo meeting, because I was dealing with a personal crisis. I'm glad to hear there's a recording of it. One of the things we didn't have a chance to do was give a presentation about what has been happening at Spritely. We're excited to try having another meeting and preparing something to show. Jessica gave a rave review about the meeting. We were shocked to see that our mockups informed the pet daemon demo. That was really nice. I think that demonstrations of not just the protocol, but the practical tech stuff, can inform all of us about what's going on.

kris: We'd be excited to have you again.

mark: (To jessica's question in chat): I think we should focus on smallcaps and try to get interop based on smallcaps. Starting there, we can see what the differential payoff is to going to something binary. I suggest we start assuming that we'll start interoperating with smallcaps. Two remaining issues: -0 and binary. Other than that I think smallcaps is in shape to use as a basis for interop.

christine: I'd like to have more conversation about smallcaps, but I think we've been making a lot of progress on the serialization front. There's been a lot of convergence, but we haven't solved all of the issues.

kris: This is part of having protocol negotation early in the process, because we can make progress on that before we agree on a serialization format.

jar: I think we should adjourn at this point.