Interim Meeting at NDSS-2018 February 17, 2018 San Diego
Note taker: Mat Ford
Dirk introduced the chairs, the IPR policy and the topics and goals of the research group.
The agenda was bashed and a proposal accepted that all present should be prepared to present on some topic related to new ideas or ongoing work during the afternoon session to maximise the opportunity of meeting.
Dirk: How do you plan to do federation? In particular, with an internal ledger?
Dirk: Federating systems that are tracking assets etc. vs. about network infrastructure?
George: IoT is superset. We have naming problems that are more significant or difficult. On the other hand, I know that problems have not been resolved in the more traditional Internet, but much of the work we will be doing will need to figure out how to name things in a decentralized fashion. We have a proposal for this, based on blockchains - unclear how practical it will be immediately - performance issues are key. Idea is to not depend on some company to sell you a specific name. Smart contract will allow acquisition of available names from any player. We expect our work will have application to the Internet as we know it today.
Dirk: Is industrial IoT an element of your work?
George: We don't have any partners focussed on that. We will focus on specific islands / use-cases. We will try to show something working there. To what extent that will be widely applicable remains to be seen.
N.N.: What stops node from lying about what function it has? And thereby getting the key and stealing the deposit?
[lost connectivity to etherpad here]
Paul Hofmann: you seem to have pushed function back to device that didn't have enough resources to execute itself
Michal: green node is receiving the request from third-party
Carsten: i'd like to dwell on result verification - you're making some assumptions here about trust - i'm trusting various other parties in your attestation system - trust is not warranted unless it creates a liability. what is your model of handling that liability? i'm getting attestations from intel about sgx platform and then next week there is meltdown - what happens? what happens financially?
Michal: don't have a good answer
Carsten: meltdown is just an example - if intel don't place value then who carries the risk?
Michal: trust also applies to protocols - answer is that we don't have an answer for now
Carsten: on the software side we have agreed to a user bears the risk approach pretty much, will this work in your case as well?
Michal: i think the same model should apply but i'm not an expert
Carsten: i'm trying to argue that you should be very explicit about trust relationships - protocols have to be very specific in this space - if you don't even have a proof of existence where that risk would be taken care of then that's a problem with your protocol
George: decentralization requires that liability is not resolved by banks but by end hosts. so it's more complicated. other players want to engage without involving banks.
Carsten: so they have to trust each other.
N.N.: wondering about approach to handle completion immediately - did you consider audit trails? so that you could discover that computation had been done wrongly some time later?
Michal: in SPOC, the result is signed by the enclave so you can verify the signature - here we assume it is a trusted function. we can guarantee that function is run on input data, bugs in functions are not a fault of the execution platform. you can verify that the computation you requested has taken place. so we are not considering any additional mechanism here.
N.N.: follow-up about the protocol - if the user lies and claims result was incorrect then he can prevent node from getting his report
Michal: yes still posisble to make someone lose money if you lose money
[discsusion to clarify protocol mechanics in relation to deposits - if you don't run computation you won't get the secret - so you can only get secret when you have wasted resources to complete the computation - incentivises honest behaviour]
N.N.: so this only works if node doesn't tamper with code running in enclave
Michal: it is signed so it cannot be modified
Dirk: this was exactly the kind of input we were hoping for by holding this meeting, so thank you
Carsten: in the end when i get a mapping from your system do i trust that or not? maybe the key to making this whole thing work is to stop thinking about this as authenticated mappings - maybe it's more useful to think about this as signed claims. might have way of processing claim that doesn't take it as absolute truth.
Sydney: good point - this is similar to how DANE works
Paul: if these are all append-only and system is meant to last 25 years you're going to have a lot of cruft - some might be garbage collectable - in your design did you come up with a way to ensure that database doesn't grow unbounded
Sydney: you can checkpoint
Paul: that's saying what's current, what about getting rid of garbage
Colin: we didn't think about that specifically but thinking about transitions might allow some operations to be collapsible
Paul: time bounding, or hasn't been any user interaction for some period
Colin: sure, can leverage domain specific things - depending on what is being stored could be treated differently
Melinda: do you have a paper that describes transitions?
Sydney: yes but for a class project so not readable
David: expiration dates in records can help deal with cruft problem - it's not necessarily obvious but there are ways to agree on time - e.g. timestamp for each time you reach consensus - so there are mechanisms available
Michal: this is what namecoin is doing - bind name to server for speciified amount of time
Paul: in namecoin blockchain old stuff is still there - i'm specifically worried about size
N.N.: not everybody needs to hold a whole copy of the blockchain
David: some blockchains have state that is growing without bound but it doesn't have to be that way - not totally trivial - but again there are techniques to make it a problem that can be addressed
Michal: hashgraph is also applicable - claim they can store all bitcoin transactions within 1GB and that it won't grow
Melinda: for the sake of argument let's say distinction between blockchain and transparency log transparency log - merkle tree - operator that extends it kind of unilaterally why not just use a transparency log when you may not need consensus about log contents?
Shigeya: operational model. can rely on third-party blockchain technology
Christian: there is an existing product on the market - iota tangle - round trip time is maybe 2 minutes not 40. It's also a PoC, see http://www.chatangle.com
George: regarding transparency logs - it's not open, it's a permission chain and you have to be on the good side of whoever runs it
Melinda: it's still auditable
George: it's auditable
David: Could this storage be compatible with multiple hip services? a common CRDT=type service - some peolpe might want to use bitcoin
Christian: yes some applications have a hard time - e.g. shared graphics editor - applications have to be tailored to account for the paradigm - chat application could be run with this system, not the same consistency as we had in the past, but i was surprised how rich the space is
david: this is a potentially appealing proposal - my gut tells me that CRDTs in a number of applications might get you 90% of the way there but not all the way there - e.g. keynet where you might have lots of email providers issuing certificates, important you can't revoke key without permission, but for scalability you want to be able to add names - is there a version of this that recognises that CRDTs aren't 100% of the answer?
Christian: if you build business logic, you pick another instantiation
David: does it make sense to stitch together CRDTs and non-commutative data structures?
Christian: I have not thought about this ripple effect
David: you might want to sandwich the CRDT in between - would help to have 3 concrete diverse applications and work out the details
Christian: i take this as a challenge!
Dirk presents the objectives of the DIN RG and reviews some of the experiences of the group to date, the kind of topics that tend to get presented and so on.
Not all of the topics we discussed really require Internet-level scalability - so we could discuss how to constrain the focus of the group appropriately.
Carsten: getting use cases is probably interesting, but what we really need to do is to identify challenges, see if they help to unite use cases - that would help to define a research agenda - well-defined challenges would be the most useful initial focus.
Paul: the two interesting words are decentralised and infrastructure. i'm less interested in decentralised, being a DNS person. but infrastructure is interesting. i would love to take their use cases and problem statements and say where this applies into Internet infrastructure - are we talking about devices (which is not infrastructure) or are we talking about middleboxes or systems that are helping the end devices?
Christian: one link between decentralisation and infrastructure is that you start to keep control at the decentralised endpoints (e.g. end-to-end encryption) - you can run quite sophisticated applications over decentralised infrastructure - we use the infra in a completely agnostic way - it's not the old infra meaning of somebody providing a service for the end users, it's changing now
Paul: if we work on infra, it doesn't matter if they're decentralised, they're helping the edge to operate in a decentralised fashion
Christian: if we can provide DNS without a root that would be nice though right?
Paul: as the co-author of RFC 7706, yes!
George: ARPANET was started with decentralisation in mind. now we have different attacks. parallel universes that can offer different ways forward are important. regarding christian's storage service, the trick is to encrypt things without knowing who will need to decrypt them. i don't know how much of a problem this is, but i think it is a problem. proxy re-encryption is somewhat related. this seems like an add-on to what you were describing that is critical.
Dirk: i wanted to come back to what carsten said - we also think it is most productive to look at the technical challenges arising from use cases. we could maybe discuss this in a more structured way in future. i found sydney and colin's presentation useful as it provided a concrete use case and the difficulties they observe. this could act as a kind of role model for future presentations.
Christian: regarding encrypted storage - deploying lambdas on amazon, you run credential-less - the infrastructure handles this - you don't need access to the key. move right now in industry is going in that direction.
George: similar to proxy re-encryption - if you have encryption to the service you trust the service to decrypt. this is a weak point in the decentralised service discussion - we try to avoid centralised decryption - proxy re-encryption doesn't really decrypt, so not powerful enough, but still has some interesting features.
Christian: motivation for DIN RG references IoT - had sense that you want to contrast that with heavyweight infra - do you really see a special treatment for IoT? aren't the infra demands similar or the same regardless of whether IoT or other contexts
Dirk: I don't think we want to play out IoT vs. other Internet infra. we started discussing IoT because we already know we don't want to rely on centralised infra. there may be different solutions for Internet scale vs. others - there may also be linkages.
Melinda: you can't assume homogeneous connectivity, regulatory environments and so on. IoT was largely just a use case.
Shigeya: how device is secured is different - we can apply different security policies for different types of nodes. blockchain can be helpful for really strong use cases. on contrary to put blockchain on IoT device is meaningless, but verifiability is important.
Carsten: there are two aspects to IoT - one is the need to be much more explicit about the security properties - need to think about what level of security we can achieve and identify the players that can contribute to the security objectives. other interesting aspect is that only part of it has happened so far - ossification hasn't set in, so we have the opportunity to find different approaches without being bound by the existing infrastructural inadequacies. biggest disaster we have to work with right now is PKI - it kind of works, but has so many undesirable properties that can only be fixed by changing some very fundamental assumptions. wouldn't like to start trying to fix PKI, would rather try to build something new. that's an opportunity but of couse much of IoT will use PKI.
Dirk: true that IoT is not as ossified as rest of Internet, but it's getting there especially if you look at industrial IoT
Carsten: industrial IoT has lots of requirements that argue for not doing what has been done before but they are still kind of re-inventing the wheel.
George: Do role change?
Carsten: Yes it does - a temperature sensor used in this room may be moved to a new room - device identity remains constant, role identity changes
Thomas Hardjono - please define 'reputation'
Carsten: i am deliberately not defining 'reputation'
Christian: service discovery naming has long history - intentional naming system
Carsten: don't know the history you refer to, but these are usually bound by a specific organisation. i am interested in trying to run on a broader scale - still requires curators, but works across multiple organisations
Paul: reputation only refers to the person looking - reputation is always in the eye of the beholder - has been work done in the IETF and people ran away screaming - you end up needing to have a way of providing different answers for every possible querier
Carsten: my hope is that differences that people care about can be encoded in the semantic identifier - we need people to voice opinions about this - result might not be perfect but it'll be better than alternative
Dirk: relaying some discussion from the chat - initially Lixia expressed some support for the idea of semantic reputation. intentional naming, despite the name, actually uses metadata to define the semantics, the name is used to get the metadata
Carsten: that's true and i'd like to do this on steroids
Thomas: I think there’s 2 things here: (a) the relationships between PI/RI/DI, and (b) the reputation of that SI
Thomas: Why does industrial IoT actually need decentralisation?
Dirk: this deserves a longer discussion, but you could argue that IIoT (in the Industrie-4.0 sense) systems would be dynamically composed of physicals systems, compute functions etc. that do not necessarily trust each other.
Thomas: agree, but good to separate out these 2 things. It's because lots of people are wanting to put “reputation” on blockchain :-)
Carsten: Industrial IoT - in software engineering we have something called process confabulation - idealised view of what engineer thinks client thinks would work. same problem arises when you ask people what industrial iot is. IoT for industry is going to decentralise in something that looks like a rogue way to designers but it's a reality.
George: is reputation only given by humans?
Carsten: no - i think there will be a lot of machine learning at play - we have 20 years of experience with people trying to play the google ranking algorithm.
George: sceptical about scalability - maybe we should also look at statistical ways of approaching this?
Carsten: yes, machine learning is just a new name for statistics
George: need to consider weighting of reputation sources
Paul: there are plenty of reputation systems built on observations of what people choose when they're looking for something - and also what they ignore. if you know some of the kinds of identifiers you can tell which kind of things people don't seem to care about.
George: one more thing - maybe reputation might not be the best term and the best approach for this - the more objective we want to make this we need a better term than reputation - need something more objective
Carsten: i think you have formulated a number of sub-challenges in this overall challenge - and maybe reputation is not the right word but in the end i would expect that we have mappings that are not exact.
Dirk: comment from Lixia Zhang: machines can certainly learn about reputations, but machines also have owners
Carsten: how to collect intelligence in a distributed way that does not require a single arbiter of what is good.
Scalability questions in global databases
efficient multicast dissemination
use set-difference based on counting Bloom filters
(federated) byzantine agreement vs. proof-of-xxx
Carsten: most of this is about implementation techniques - something done locally - without necessarily influencing other domains
David: this is protocol level
Carsten: are you sure? what optimisations can you do without influencing the protocol around the domain you are optimising?
David: in my experience, not a lot. optimisations tend to impact the protocol level.
Carsten: term local is relative here - for someone throwing things into a log, may not care how you run log, but if optimisations requires specific form for log entry then maybe i do care
Carsten: i'm trying to say there's a difference between 'needs to be standardised' and 'needs to be standardised'
David: i'm talking about how machines share data as things that need to be standardised
Carsten: even if we standardise cache-digests, not every browser has to understand - important to only standardise the things that really have multi-domain applicability
Paul: some of these are really cryptographic questions - and we can throw stuff like that to CFRG.
[ discussion about what is a DHT and what is being done in IETF / IRTF ]
Lixia in the chat: "The design and implementation of an intentional naming system"
Christian: http://nms.csail.mit.edu/projects/ins/
Dirk: IPFS, Maidsafe exist and do some of this - is this what you had in mind or not?
Shigeya: IPFS replaces the filesystem, so not quite what I'm talking about.
Carsten: activity to define security.txt for a website that would describe who to contact in the event of website compromise. what's missing is a way to attach some metadata to a website in a way that does not share a single point of failure with the webserver itself. this is one example of where we want to provide information about resources when the resource itself is unavailable (e.g. because it is a low power IoT device that is asleep).
Remember the past, 1997 - rise of the stupid network -> the rise of the stupid infrastructure - e2e-encryption, trustless, your definition of scalable etc. ... just follow the libertarian impulse behind blockchains
Dirk: by avoiding the big players you didn't refer to blockchain mining corporations
Dirk: you might have good reasons to not go there - global ledger bottleneck might not be the answer
Dirk: are there any other thoughts or ideas whether on slides or not that you would like to share with the group?
Christian: what are the expectations on the social plane regarding the research group?
Dirk: great question - that's what we're going to discuss during the remaining time. we can run these groups in different ways - a forum for sharing results and so on. We'd like to try a bit more of a constructive approach - trying to identify commonalities, shared approaches. now in community building phase, we are planning to meet again during IETF 101 in London - Monday mnorning slot for 2.5 hours. we will need to be focussed. would like to move from pure presentation discussion mode to writing things up for sharing, posterity etc. depends a lot on what people would like to do - we are contribution driven, but would like to make an effort to structure this a little bit. let's discuss.
Carsten: output of an RG need not be limited to documents. Running workshops is an important output if they are succesful by some metric. Managing wiki can also be useful for structuring and sharing information. Dissemination is important. Reaching out and integrating a community is very useful.
Melinda: IETF has tended to kick distributed computing questions down the road, e.g. rserpool. Anything to do with state migration or sharing was ruled out of scope. Increasing interest in shared state in distributed environments. So we don't really have a way of establishing consistency in CT logs, starting to come up a lot. Providing input to IETF is an important activity as well.
David: Would protocol spec be in scope?
Melinda: Sure.
Carsten: IRTF RG can do experimental and informational RFCs, not standards track.
Melinda: Getting an experimental RFC would be worth my time.
Dirk: An IETF WG is expected to converge on a common solution - not necessary for an RG. We can publish specs on specific approaches, whether competing or complementary. To encourage people to do more experimentation.
Melinda: An experimental RFC is expected to represent consensus whereas an informational RFC is not.
Dave Crocker: RFC editor defines labels, streams define how they get applied
Paul: Write up BTC consensus protocol in a way that allows comparisons with other consensus protocols.
Melinda: There's lots of distributed ledger activity - people have other outlets for participation - need to distinguish DIN RG from that other work.
Paul: As an outisder much of what I see there is advocacy not description. Would prefer some more neutral analysis of various consensus protocols, should DNS be on blockchain etc.
Dave Crocker: just taking the DNS question - how does one evaluate competitive designs to achieve that? having a document that provides a framework for that analysis - set up a template of topics issues criteria that are considered important.
David: i see a lot of people kind of misusing blockchain - only gives you two things - coin distribution and transaction ledger amongst untrusted parties. can we short circuit some discussions about whether blockchain is applicable?
George: As part of SOFIE project we are doing a state of the art review - will focus mainly on federated IoT systems but we expect to have small sections on blockchain and consensus in particular. we will try to have some kind of comparison. will share in 6 months or so and if it is of interest we can work on it here.
Carsten: we are not the 'how to prevent mis-uses of blockchain' research group - should focus on actual challenges.
Dirk: there is competition for attention, what communities should we talk to, are there people we should try and get to these meetings?
Carsten: Banks?
Paul: No. Let's keep it to distributed infrastructure - banks might be interested at some point, but reach out after we have some documents. We could get started and then consider finding people who might be interested in some of the work items.
Melinda: there are people working on this who are engaged and not coming because there are so many other venues for discussion
Paul: are there groups of people doing non-blockchain ledger work?
Melinda: yes - google folks who did trillian, generalised transparency mechanisms, directed acyclic graphs, there's a lot going on
Paul: is there a way to get people who are not focussed on block chains engaged?
Melinda: there are folks in England that we can get to London even though they might not travel elsewhere.