OCapN Pre-standardization Group

July 2023

#70 Agenda

Minutes

jar: was absent from last meeting, going through outputs, including assigned issues. Ian raised 3rd party handoffs

tsyesika: I believe one of the things was to go through the concrete syntax provided by Agoric folks? Doesn't have to be at this meeting but would be happy to hear presentation by Agoric folks

lothar: Gist is, it's json, strings encode most of the rest of things

jar: should we put it on the agenda for next time or talk on this meeting?

rgibson: reasonable to put on agenda for next time

jar: I'll talk to Ian offline about assigning someone to 3rd party handoff issue. Clearly if that came up at last meeting that should be moved forward somehow.

Closed issues & PRs

jar: ok so we have this convention of asking people if they want to object to the closing of issues. I've listed the ones I've defined

kriskowal: would like to talk about symbols and normalizing method invocation between languages

jar: could you reply to or add issues about these?

kriskowal: yes (the relevant issues were and remain open https://github.com/ocapn/ocapn/issues/46, https://github.com/ocapn/ocapn/issues/62)

jar: re: assign additional feedback to captp spec, going to assign to tsyesika

tsyesika: you can assign to me, there are a bunch of changes in test suite and things I was dealing with. You can go ahead and check.

jar: ok more substantially, have these two items, first requested by Ian about the e-order vs point-to-point ordering guarantees. he believed there was some confusion around that still and it was discussed. Since he's not here I think it would be good to go through

#40 E-order vs point-to-point

cwebber: I have opinions

markm: me too, but not up to date on controvercies in group

cwebber: Ian isn't here so how about we move to next meeting?

jar: that's my inclination

#29 #73 OCapN Locators

[jar note to self: rename issue]

tsyesika: I named OCapN locators because URIs were previously controversial

tsyesika: so we have sturdyrefs which are a reference to a specific object on what's called a node, was previously called a machine, because there was confusion about there being able to be multiple nodes on a machine

tsyesika: takes "locator" which is typically a self authenticating designator, a netlayer identifier, and a set of hints. any additional connection routing can be in hints. sturdyref has swissnum in addition to all the ocapn node information I just talked about, identifies an object on said node. These have a syrup representation and a string'y URI representation for bootstrapping out of band. Assumed you'd use the syrup one usually for in-band, but for out-of-band the stringy thing is helpful. Spec is quite small and follows what I've previously suggested. Netlayers document is perhaps smaller than that, I thought it would be bigger, but I guess due to the design of netlayers, in Goblins they're just a bidirectional channel between two captp capable nodes. So there isn't much to them. The document is split up into two small sections, one which describes what a netlayer should be, what kinds of properties it exhibits, what the spec expects you to define, these items to build up this ocapn node structure, and there's one netlayer defined, I'll probably define the other netlayer that goblins supports, the tcp/tls netlayer that dthompson created. Pretty simple, not to much to it based on how its designed.

tsyesika: So those are the two specifications, I don't have strong opinions, but should the specific netlayers be defined in the netlayer document or should they be defined alongside because I assume there will be many more over time. something to discuss. for now I put it in the document, I can move it. And yeah.

cwebber: will be helpful if you can walk us through it, can you present and walk through?

tsyesika: yes (begins screen sharing)

jar: ack markm

markm: so I agree there will be more concrete netlayers over time. the particular other one that opens up a lot of the issues/challenges of what is universal for designators across the network is IBC. Agoric is doing commmunication over IBC, the Inter-Blockchain Communication protocol. The particular idea which I think was assumed was that there was a swissnum, and that only works if endpoints can keep secrets, and in a blockchain endpoints cannot keep secrets. So we've gone to a fully c-list oriented approach. In E, the handoffs were also c-list, and supplemented by swiss numbers. The thing that's challenging from going to... oh, a terminology distinction in E conversations, I think you guys are using the term sturdyref for what's properly called an offline capability, something that's meant to be conveyed by out-of-band media. basically a captp uri string to be conveyed by a QR code or etc. those are the offline capabilities, and then a sturdyref in E is a first-class object that is opaque to other objects holding it, and encapsulates the things needed to re-establish a connection. And in E that was encapsulating the same thing as in the offline capability. the sturdyref was not revealing the things for the offline capability, that was important for offline capability. I think those were the points we want to make. I support the notion that in the document there are other netlayers to come, if today's concrete netlayers get moved to additional documents, that's clarifying. I think we all need to look at IBC and see if it fits into the overall framework and whether or not we can

jar: we can put comments in the PRs but I prefer to have issues to track these. I didn't know this was coming along, and that would be a great place to come along

cwebber: I agree that IBC is important as an example. We are planning on looking at it but haven't yet. It's been on our list since the beginning and we have conversations about the importance of supporting endpoints that cannot hold secrets. I also wanted to say that we do what you are saying in Goblins, and to some degree we do it in the spec. In Goblins, there is an internal data structure for sturdyrefs. There is a separate procedure for converting them to strings. They are transferred across the wire in CapTP as syrup records, as Jessica mentioned, so they don't have to be coerced to strings to be sent across the wire. The stringy URI format that Jessica has described is just a particular encoding of a sturdyref. Does that cover your concerns, Mark?

Mark: Yes. (Missed the full response)

cwebber: Maybe we should make a note in the spec about the convention to use structured data, not a string.

Mark: Right, and the string form would be needed for interop. I want to reserve "sturdyref" for the structured representation.

cwebber: We've been saying "sturdyref URI" to refer to the string.

Mark: I have no objection to that.

tsyesika: Yes, these do requires you to hold a secret, or at least the ocapn sturdyref does, and Goblins did have other kinds in mind, and we assumed the document would grow to have different types, including maybe a different record label, and here in the URI format we've taken the format of having /s/ for the sturdyref, allowing for different URIs which don't hold a secret. If you're using a different uri structure perhaps we could add that now, that's no issue. We had certificates and bearer unions as ideas for different ways of encoding. Neither of these have support in Goblins yet but obviously we could have other types. I think offline reference

Markm: I would say offline capability. The URI adjective takes care of my entire concern.

tsyesika: they don't have the uri thing when referring to the syrup structure, there are ocapn sturdyrefs

markm: ocapn/syrup sturdyrefs are in-band right? then that's fine

tsyesika: yes. we've been calling those ocapn uris, they look like this, they have this format

markm: okay that's great

warner: I think the salient point is that code that has access to these have no way to access the string. need to be able to encapsulate confined code and not have it extract the secret

tsyesika: yes, that's the way Goblins is also designed. the spec doesn't touch on that but it could

cwebber: could we make an action item to file an issue to address the following: the sturdyref as an abstract data type with in-band representation, the sturdyref uri as a particular encoding of that, and the recommendation that implementations have a specific capability to coerce into strings to enable confinement

markm: useful link: http://erights.org/elib/capability/dist-confine.html

jar: ok we have two documents to cover, 36 minutes into our time. want to make sure we know how to comment on this draft, we have two methods I guess, one is to make amendments to the PR, the other is to add comments to an old issue and one is to make a new issue

tsyesika: was wondering, could I propose a method to bring these things up in github?

jar: go ahead

tsyesika: my proposition is that anything that people would consider a blocking change, something they would want fixed before these are merged should be brought up on the PR, and then others as new issues so they can be addressed individually

jar: this is what you suggested earlier and that sounds good. will make a note to myself to close the original issue.

jar: ack kriskowal

kriskowal: With regard to the sturdyref URIs, I note there's a single transport in the URI and multiple connection hints. and those are hints right, so those could be like an IP address?

tsyesika: yes

kriskowal: something I am anticipating is that there will be peers which can only use certain sturdyrefs and whether we should have multiple listed

tsyesika: in Goblins we have discussed this, have discussed a way of having multiple locators specified and then have those as the data that's provided there. have something that can encompass several other URIs. That hasn't been defined yet, but that's one way you could do that

kriskowal: concretely that could be like designator.mux and then tcpip hint 2... etc etc

warner: there are subtleties where there are multiple ways of connect to the node, there are ways where there are multiple connection was incoming, there are multiple tcp ip hints, anything to get you a byte byte, but if you're using a cryptographic address where you're relying on something with underlying security like onion addresses having a specific key

cwebber: There are multiple security concerns that need to be considered when there are multiple paths. This already exists with hints, but ignore that for now. As Brian said, if there are multiple abstract identifiers in terms of different keys... For example, if we have the Tor onion service and a .onion address, we can say that is the secure key. But once you add it to the composition, such as Goblin's tcp+tls netlayer, you get a composite capability that has a risk. It may seem like there isn't a risk initially, so if it says there are different paths then it is fine. But since we do a bidirectional connection, if Mallet says here's a composite capability with Alice's address and an address that Mallet is running, could the system get confused and route traffic through Mallet in a way that is harmful. There are risks already with hints. Mark and I discussed this on the erights list before. To my memory, Mark said "that wasn't a concern in the E days, but maybe it's a concern today." If the keys "don't matter" (unsigned) then there's a potential risk where an attacker can do a network monitoring attack so Mallet can see when Alice and Bob are communicating. Even if Mallet can't tamper with the traffic, Mallet could know when they are talking. Mallet could also periodically drop messages, which would be hard to diagnose by Alice/Bob. Do hints need to signed to handle network monitoring

warner: those are important concerns, especially privacy and network monitoring, and most algorithms don't seem to be concerned. the protocol assumes you could connect to all endpoints and only the right messages go through, and privacy I haven't seen well encapsulated in any protocol like this

markm: mostly echoing what both christine and brian just said, making the distinction... it's important with the hints to talk about addressing integrity, confidentiality, availability. the threats are very distinct here. the hints themselves do nothing for integrity, the locator does that. the hints... and by the way, most systems do that, they rely on a DHT or some assumed routing fabric where they can start with the crypto material and look things up, and the risk is denial of connection, 3rd parties who can deny a connection. the hints are a first good defense against a denial of routing attack, but christine's point that if the hints are provided without a verifying intermediary, they can be leveraged to cause leakage that violates confidentiality

Next meeting

jar: next meeting on normal meeting time

markm: august 8th? looks good for me

#72 Netlayers document

tsyesika: This document is on netlayers, it briefly describes what a netlayer is, that captp is agnostic to it completely, assumes it's a bidirectional channel that allows for transmitting and received. and the messages should be delivered if the session remains active. The messages are FIFO between the two parties, and only the two parties involved in the message channel can insert messages into this channel. Interestingly this has some properties that might be considered desired, certainly we do at spritely, one is the reachability of nodes without further configuration from the peer such as NAT hole punching, etc. for 3rd party handoffs it's important. and that it's encrypted, not required, but it's desirable. and each netlayer should provide what information goes in the locator, which is typically a self authenticating designator, the netlayer identifier, the hints, and then here's where the document describes a netlayer (the tor onion services netlayer) and it fits on one screen including why you might want it, and that's largely because tor describes how it's implemented. specifies that you should use tor onion addresses over a particular port. you can see the document is small, based on what's defining a netlayer, and due to it being a channel, if the word connection appears that's a bug, can be connectionless, so as long as you can get messages in directed to you and send messages, all is well. that's the netlayer document, pretty small.

Other topics

markm: since warner is here, would like to invite him to say something. Brian and I recently walked through the properties that I always assumed CapTP could have universally. Brian made me painfully aware of some of the additional constraints of having a blockchain as an endpoint and which make me very worried about what we assume are universal of all captp endpoints might not be.

brian warner inaudible presently

markm: okay, I will leave that

cwebber: just commenting on simplicity of current state of netlayers mirroring vattp of simply bidirectional messages

Jessica's grant update

tsyesika: documents are mostly done, there are a couple of things left in terms of captp document that need to be resolved in goblins' implementation and then the generalized tests especially around debated parts like op:pick. then the next piece of work is implementation guide, probably a lot of diagrams taking inspiration from mark's diagrams because they're quite good

cwebber: just want to acknowledge jessica's incredibly hard work on these documents

general applause and comments of appreciation in the chat

jar: okay at that point I suggest we adjourn, thanks everyone! see you next time!