Internet Engineering Task Force 104, 27 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-DINRG-20190327-0900

Description

DINRG meeting session at IETF104
2019/03/27 0900

https://datatracker.ietf.org/meeting/104/proceedings/

A

Okay, domani Mitzvah, so why can't? This is Dynegy, so decentralized, internet infrastructure for those who are here for the first time. So the energy is concerned with, like applying, distribute computing to decentralizing internet infrastructure services, some of a loose definition- and this is not a sure, I'm sure- and just before we start the usual IRT FIP our policy, which follows the IETF IP a policy.

A

So in short, you have to inform us if you talk about or way of any IPR in any contribution to this group yeah we have the usual infrastructure main in this wiki and so on. The most important thing is that we need a note-taker to for today. Otherwise we can't really do this meeting, and so that means we did a volunteer for that.

A

So usually in note-taking captures the discussions after the presentations and yeah.

B

A

That's really important to have a record of that and enable people to follow. What's going on.

C

D

A

You right so the M, if feel free, to use that the eat a pet, if you, if you like, but you don't have to so we have an interesting agenda again so talk and so in previous meetings.

A

The issue came up that what some of the consensus protocols that we interested in actually need a reliable and scalable and secure communication infrastructure, so David Mercier and colleagues kindly started thinking about this. So talk about that, we have a presentation by Kristen on the name system we have Nathan and from Singapore joining remotely on a Byzantine agreement protocols. And how do I prawns again I'm correctly Brooke Brooke Brooke is talking about new funding opportunities on next-generation internet in the EU that relate to the topics that we work on here.

A

Any comment any need for bashing the agenda, all right and let's get into it, and we start with David's.

E

A

F

Thanks so yeah, so I, I'm gonna start with a little update cuz. You know, for the last end of these meetings, I've been telling you about this consensus protocol and the draft. That's in in progress on this I think the draft has kind of more or less stabilized at this point, at least for the moment, and also we kind of wrote up a short like six page version.

F

So if anyone has been like you know wishing they could understand this protocol better and wishing there were like a simpler description, you could try the simplified description which I've linked to in the slides here. There's a lots of hyperlinks in these slides which you can get from the materials, but there's kind of a you know. What I'd like to do is get this draft to the point. There are multiple implementations where we can actually start like baking off one implementation of the consensus protocol against another. But the point is as we're going now.

F

This never gonna happen. Why? Because the draft doesn't specify what the underlying broadcast layer is, how these messages actually get exchanged and the reason for that is that there's not really a solution. Necessarily that's that's kind of good enough with that.

F

At this point, particular there's security issues with you know most kind of existing approaches to overlays and the goals for st-pierre to provide very strong security like to be able to send large payments over this thing or use it for kind of secure software or firmware or certificate transparency logs or you know, secure IP prefix delegation, things that you know it might be cause a lot of damage if someone messes with it, and so that means that we need some kind of secure underlying multicast layer, and so that's what I want to talk about today.

F

It's mostly not my work, it's more like kind of a survey of past things and might be ideas, and you know there are no solutions here. It's mostly questions, but if we come out of this- and you know, we gauge that there's kind of interest in requirements that can like help guide the research so obviously like an area that I'm interested in working okay.

F

So, let's start with kind of as a motivating example, the Bitcoin overlay Network I think it's fair to say that the kind of resurgence in interest in decentralized infrastructure is probably at least indirectly due to like the excitement in Bitcoin, just to say, like 20-year 50 years ago. Eighteen years ago, is because of peer-to-peer now because of like peer-to-peer networks and distributed hash tables. So what is Bitcoin do to disseminate messages? Well, the typical Bitcoin node is configured to have eight outgoing TCP connections and to allow up to 117 incoming TCP connections.

F

When you start up a node to join the network, it goes and fetches a bunch of pure addresses from DNS seeds. These are like DNS names like dinna, like seed, the Bitcoin stands calm and then, once you connect the nodes, you get these messages nodes can send you.

F

These messages over the overlay network called the address message which contains a list of like a thousand other peers, and so you kind of learn about more and more nodes in the system and what I know it actually does think it divides us that appears that learned about into two different tables called the tried table and the new table and the try table is basically known good peer, so every table every node in there has a timestamp.

F

So you know, you've talked to it at least at some point in the past and the it's divided up into 64 buckets of 64 entries. Each the nodes are kind of hash based on IP address, and the hashing is done such that for any given slash sixteen prefix. It can only have two one of four buckets, so the idea being that maybe, if the attacker controls only a small number of IP prefixes, it's harder to like take over all of your buckets right.

F

But you know that's thus dicey, proposition right and then, when you evict something from a bucket, you basically pick the bucket. You pick for random nodes, the one the one with the oldest timestamp gets demoted, which means you move it from the tried table to the new table and then the new table is where you put all the new peers you hear about.

F

So that's 256 buckets of 64 nodes, each and again there's a it's based on hash of IP address, but there's some bucketing so that, if you- but here the bucket name- is based on like the also based on the slash 16 of the node that actually the address within the hopes that someone can't just completely give you tons of garbage for all your buckets if they send you a bogus address command.

F

So when a connection is dropped, you reconnect to a random node and, depending on you know how many incoming outgoing TCP connections, so so, when you have it you'll either connect to a node in the new table or the tribe table. Okay. So that's how Bitcoin works. What's the problem? Well, the problem is that Bitcoin is vulnerable to these, so called Eclipse attacks right.

F

Where what happens is you use a botnet to own a whole bunch of different IP addresses, so you can kind of take over all the buckets at least theoretically, and then you find some victim node and you connect 117 times. You know every time it drops a connection. You're you're, the next one in so you're kind of monopolizing, all the incoming nodes, all the incoming TCP connections, then you give a bunch of address commands that contain only the IP addresses of your nodes.

F

So eventually all the outgoing connections are gonna, be to your nodes and you've now completely surrounded this node, and so you can kind of give it your own tailored view of the network, and so by controlling the view of the network, you can do things like engineer, block races like waste a whole bunch of CPU time by making a minor, o expend energy mining a block. That's just gonna, be an orphan block because you prevented them from learning about a new block that they should be money on top of there's these selfish mining attacks.

F

Where you mind a block, you don't tell people about it, and then you kind of make them waste time, and then you publish a block. If you can do. If you do eclipse attacks, it makes those the selfish mining attacks much more effective, but there's an even worse thing, which is that proof-of-work is a consensus as it consensus. Algorithm is actually completely unsafe in the asynchronous model. Right is a fundamental assumption that there's only bounded communication delay between nodes. Otherwise it's not a it's, not a safe consensus algorithm in particular.

F

If an eclipse attacker can can impose arbitrary delays in communication, then what an attacker can do is even without controlling any hashing power. They can kind of split all the miners up into different groups and therefore use the existing miners to mount the spend attack by having for the the good well-intentioned miners actually creating a forked history.

F

Ok, so so I've been telling you all about SCP in the last few meetings, so you may say: well, wait a sec, isn't one of the big advantages of SCP that it's in asynchronous protocol that SCP is actually safe. Even if there's unbounded network delay and the furniture is yes, this is great. You know, unlike proof-of-work, these Byzantine agreement, type protocols in the family of pbft and and and SCP, they are safe, no matter what the the network.

B

F

Is like so what's the problem? Well, the problem is that there may be layers on top of the consensus that are not safe in this asynchronous model, and so a good example of this would be, let's say, you're using a blockchain to do payments, and you you you, you you've set up an escrow account, so it's an account. Maybe it's a multisig account. You require signatures from me and from you to access this account and what I've done is I've sort of pre signed some message that you know allows you to withdraw.

F

If you want, you can submit and withdraw whatever portion of this. Escrow account belongs to you, but in case you disappear. You know in 24 hours I'm allowed to claim the entire contents of escrow account for myself right, and in that case, if I can prevent you from submitting a transaction for 24 hours, I could actually just steal your money and it doesn't matter that the underlying consensus protocol was safe because the sort of higher-layer replicated state machine had these things like time, lock transactions that actually depended on time.

F

So and of course, it's really cut the other kinds of things we're talking about using these, these global consensus protocols for things like you know, software update logs or like revoking vulnerable software, and these are all things where you don't want there to be arbitrary delays for actually getting getting getting the stuff out there.

F

Okay, well, you know believe it or not. These overlay networks are like pretty well studied and in fact the you know right now.

F

People are excited because the blockchain, but you know 20 years ago, people were excited because of peer-to-peer networks right and- and so in fact there was a fair amount of work talking about multicast in that context, and so the kind of method, the more tame end of the scale there are people saying you know, maybe the mbone isn't you know, maybe IP multicast isn't the right thing and we should be doing n system multicast, and so the nerado work at CMU is a good example of this, where they basically formed in mesh network of like a bunch of nodes, and then they ran a kind of routing protocol.

F

On top of this, and you could set up a bunch of multicast trees- and you know, work pretty well, but it was kind of intended for maybe like thousands of nodes, and there wasn't really an assumption of that.

F

There was that there were malicious parties trying to attack this thing that there was like a large bounty involved in in like denying service for a while, so so that another kind of line of work that was that was a little more out there were these distributed hash table or DHT based multicast is this kind of structured multicast that is designed in such a way that it can scale to potentially millions of nodes be very efficient, like you, don't receive redundant copies of messages and stuff, but it was kind of brittle in the face of failure, particularly Byzantine failure, and we'll talk more about that in a few slides and kind of as an alternative to the structured multicast.

F

There is unstructured which multicast, which are kind of these gossip based protocols and those tend to be more robust to node failure, but they're more wasteful, like you, might get multiple copies of each message and whether or not they're scalable depends on whether you have a partial or a full view of the system. So in a full view, gossip protocol every node knows every other node in the system, and so, if you scale that up to millions of nodes, it will actually be a fair amount of traffic just maintaining with membership information.

F

It's a partial view. You only need to know some small, much smaller number of nodes that are sampled from the whole system. So again, maybe these are better for failures, but they are still vulnerable to Byzantine failures right, particularly the partial view model. Okay.

F

So for anyone who came of age after the early two-thousands, here's a review of what a distributed hash table is the ideas and examples of these are like cored pastry Kadam alia is I have up here. That's one that my student did that's used by tracklist BitTorrent. Now the basic idea is that every node in the system has a random ID randomly assigned ID, which is like a 160-bit number and it's basically a large distributed key-value store.

F

So if you want to store particularly key value pair, you hash the key down to 160 bit number as well and use for the key on the node, whose ID is closest to the key right and close. The definition of close depends on the distributed hash table with Ken Emily is just X, or so you take the XOR. And so basically, if you kind of agree, if the key and the node ID agree and the top number bits, then it's going to be close.

F

Otherwise, it's not and the way the DHT works is that you're no less here this black dot node here you need to know like at least one node who's, not in your subtree at each level of the table right. So here your this node here and you on the right hand side. So you have to know someone on the left hand side of the table, but then you also need to know someone say you know in this subtree that you don't belong to you and this subtree that you don't belong to.

F

So what happens is by knowing kind of login people, one person who's that who differs in in one bit from you going from the most significant bit each level, the tree you can route to any key in a log number of steps right. So in this case, if we are the node, ID is 0. 0 1 or the the starting node is 0 0 1 1, and it's trying to find the key. That's like 1, 1, 1, 1, 1, 0, right and so well.

F

Maybe it just happens in a 1 node whose node ID starts with 1 and that node is over. Here. It's a node whose ID starts with 1 0 1, but it knows someone and like a little bit closer and this one there's some little closer and eventually you get there in in log n steps. So so you can basically use this for for multicast doing this technique called reverse path, forwarding and so a system that did this was scribe, which was a multicast that ran on the pastry distributed hash table.

F

Basically, your multicast group is named by some ID and there's some node, that's closest to that idea. So that's going to be the source use forward all messages there to start.

F

You know that's where they start from multicast and then, if you want to join the multicast group, what you do is you route a message to that to that route of to that source and that route goes over kind of login many steps and the node the internal nodes that you you talk to form kind of a multicast tree, and so so, with a nice kind of like log fan-out, you were able to reach an arbitrary, an arbitrary number of people in just you know any individual node only sending like login times the traffic and only login depth in the tree.

F

So one disadvantage of this approach is that it's unfair. If you're in the middle of the multicast tree, then you have to forward a bunch of traffic and if you're at least, then you don't forward any traffic, so split stream, which is pictured up top here kind of fix. This problem by saying, instead of one multicast riyals, have a forest of multicast trees and we can stripe the data over all of these.

F

So you can see any given node like this node m here, it's gonna be a leaf in all, but one of the trees and it'll be an internal node in one of the trees. So it's kind of fair in terms of the upstream bandwidth that you have to dedicate to this right so and you with striping. Maybe you can also add some forward error correction, which would be good okay. So so the problem is that all these dhts have have a bunch of security issues.

F

There was a good ACM computing surveys, kind of retrospective about all the security work a few years ago, I basically kind of divided it up into three categories of problems, which I think is about right. So one or civil attacks right, which says that an attacker can join many many times and so basically overwhelm the nodes overwhelm all the good nodes would be like virtual nodes controlled by the attacker.

F

The other is a quick Eclipse attacks which are where you're kind of poisoning the routing table, and then the third are these routing and storage attacks. Where you essentially engineer your node ID such that you control all the nodes near some important key, and then you can kind of throw away that key. So in terms of what this means for the latest generation of I think the things that we're now interested in for for that require multicast civil attacks are potentially a big problem.

F

When you look at everything that the people did back in the day, you know they did kind of admission control by assuming a certificate authority right. We don't want that they did so based on IP prefixes. That was not really good. If you have botnets, they did stuff based on network characteristics, to like figure where you are in the network. But again you know with Nets. That's not so good.

F

You know they were actually protocol protocols that, like involved like examining social, the social graph right, where, maybe you like know some nodes best thing better, like some idea, like civil guard, did this thing with, like quotient, cut and social graph, the idea being that groups of bad of Sybil's were probably not that deeply connected to good people, proof of work incentives, so some of these are relevant. None of them would really like totally solve the problem.

F

I do think that with SCP there's at least an existence proof that we can have decentralized protocols that invalidate assumptions of the civil attack right. So what SCP does is, because it invalidates, is the simple attack paper assumes that you don't have any physical knowledge of the nodes. Who are your peers right that they're all just like these anonymous nodes out there and with with quorum slices, which I'll talk about ICP a little bit yeah and that that invalidates that assumption?

F

So at least, maybe provides some way to get around to civil attack, so I'm not sure how to do it from multicast for Eclipse attacks.

F

You know a bunch of kind of again like analysis stuff that maybe is relevant again for the routing of storage attacks. I think those are less Roman now, because that was when you were sharding your data out over a whole bunch of nodes, and least in the blockchain space, we're talking about highly replicated systems where everyone keeps like a complete copy of the system. So maybe maybe those aren't an issue now, okay, so that was DHT based multicast. The other whole group is these unstructured multicast that are these gossip based systems.

F

So the basic idea is really simple: you kind of send every new message to K random peers, and so eventually, as well as like they'll, be like epidemic propagation, so we'll just kind of reach out to everybody in the system and after after a few rounds, everybody will have heard this message, so the big problem is, of course you have to pick these K random nodes and the obvious way of doing it, which is everybody knows all the nodes, runs into scalability problems.

F

So that's where this partial view idea comes and a good example of a partial view. Protocol is the high part view protocol and what that does is a little bit like Bitcoin. It maintains these these two routing tables like an active and a passive, the active peers that a node has a symmetric. So if your my active peer I have to be your active here as well, and that's where you actually propagate this stuff, but then as soon as an active peer fails, you've got this kind of reserved list of passive peers.

F

We can immediately find another one and and plug the hole. The way the passive sets are maintained is through these shuffle lists. You kind of take a whole bunch of peers that you know about and pack it into a message and main this message and that maintenance message gets forwarded to like a random walk like some number n of hops, so basically like each node keeps sending it to a random peer and then, when the time to live, goes to zero. Whatever that peer is then processes.

F

That message adds the nodes it learns about the it sends you back a bunch of passive nodes that it knows about, and if it has to evict nodes, then it affects the ones that it just sent you or, or you know otherwise, fixed randomly and then the active set is maintained because, like your TCP connection, resets or something so you know that node is not available anymore.

F

Okay, so one problem with with this kind of random approach is it's not necessarily very good for a network locality right? You can, for example, end up sending a message halfway around the world and back when it was going to like another computer in the same room right because again you're just sending it to two random peers. So this idea of having biased.

F

Selection appears with words, so you can kind of buy a superior race in a way that makes the protocol more optimal for the network and what you want to do is kind of probably bias your choice of some peers, but also still have some random peers so that, if you're you're biased thing makes makes it unsafe, you can always fall back on these other peers. That really are random and then stuff still will actually propagate through the system.

F

So a good example of a system that does this is X bot, which is an overlay network that has this strategy where, let's say you're, some node I here and you you have one of your your peers. Oh and there's you have another peer see, that's not one of your active peers. You think C is better than oh. You think it's you're closer to it on the network, so you don't want to kind of reduce a number of links in the system, because that would that would potentially hurt the the availability of the system.

F

So you want to kind of transform the the graph in such a way that you're preserving the number of links, so you kind of go through this. This multistage process, where we end up, is this other node see pick some node D that it wants to offload, and so you start out connected connected to, oh and in the end you're connected to C, but then o is connected to D, so you havin really reduced the number of links.

F

So one question: this is obviously only done in the context of performance, but then it you know it raises the obvious question: should we think about maybe biasing peer selection for security? You know it's to make these these things more robust.

F

So another thing that people have tried is hybrid approach where you have kind of it's a gossip protocol, but it also uses some elements of the structured multicast approach. So like plum tree is an example of this. It is that you separate your peers into like eager push, peers and lazy push peers, and any time you receive a message. You immediately send it out to all of your eager push peers except the one that saved them.

F

Obviously, and then kind of in the background you said not, you send out the full message to your lazy push peers, but just like some message: ID.

F

But that way, if there's some failure in the eager push appears like people will still hear about stuff, and then they can request the messages and you basically you you start out and put everybody in your in your eager, push peers and then, basically, as soon as you hear a message, multiple times you anybody who sends you were done and copy that message all, but the first person you kind of downgrade them to be lazy, push Pierce and.

B

This is a symmetric.

F

Relationship, whether you're, you're, eager or lazy, so basically, what happens? Is you start out with this mesh and very quickly? It becomes a spanning tree and then it can also repair itself fairly quickly, because you do hear about these message. Ids and kind of batches of of in batch messages from your lazy push peers, and then you can also just upgrade a lazy push where you actually upgrade that if you were missing a message- and you wait for time out in that- you still look at the message.

F

The first person who told you about the message- you upgrade them to be an active here. So again, this idea of maybe like disseminating message IDs, maybe if they're, cheaper than messages or send even more compressed version like a bloom filter or something could could help identify bad nodes.

F

Okay, good, so so, there's a bunch of other work on kind of secure gossip and secure dissemination of messages. This stuff. You know you look at the titles and abstracts they sound pretty good, but it seems to be solving kind of like a different problem. So, for example, there was this work on targeting malicious gossip, but it's it's got. The the problem is set up in such a way is very like sort of very much like the closed bft model.

F

Like you assume, there's no more than T failures, and you know you assume, there's some number K greater than T of nodes that are initially seated with the ground truth and just need to get this out there. So I, don't think these ideas are directly applicable, there's. Maybe some interesting techniques like path, verification where, when you get these messages that haven't been did ya, you have a path of every place.

F

The message has been forwarded through, and so you you try to get messages that have disjoint paths, because those are because then no single attacker could be could be messing with all of them simultaneously.

F

You know: is there some way to adapt this to kind of irregular, open membership systems like we're talking about here, I, don't know, but it's something worth keeping in mind. There's a system called fireflies, which was actually multicast systems specifically designed to again withstand malicious nodes, and if the model is superficially appealing you're, saying: okay, we've got nodes that are correct nodes that have crashed and nodes that are malicious, but then it kind of assumes that that there's at most some fraction, P of non crashed nodes that are actually malicious right.

F

So again, this feels very much like a closed system. The kind of key ideas involve nodes, accusing other nodes and kind of broadcasting, this information to identify who's, bad and malicious, and then, of course, you have to worry about nodes in fault, bad nodes, falsely using good nodes. So there's some way for good nodes to mask some number of accusations, but not too many accusations and so on and again the idea of monitoring noise monitoring nodes, sound superficially, appealing I, don't know!

F

If we can, we adapt this to something that doesn't require admission control, I'm, not sure. Okay, there's also these intrusion, tolerant overlay networks and the so here there was so the system called like on seems kind of interesting. It sort of repurposes research on ad hoc mobile wireless networks and and all the packets are source routed, and you have this failure.

F

Detection based on kind of end and check so is stuff getting through it seems seems, and then, if there's a root seams battle, then you quarantine it for a while and then it comes back later.

F

So you know the the first of all. This is geared towards unicast. It is good that it reacts well to these two. You know a very high fraction of routes failing, but it also internally like under the covers uses flooding to kind of get rude messages out there. So that makes me think well, is it gonna be very vulnerable to like amplification attacks and stuff?

F

It seems it seems, maybe a bit problematic, okay, a couple of other ideas, so this this was an idea that a student of mine had a number of years ago, antenna Nicolosi- and this is more geared towards structured multicast again, but it is, let's say you really did have a structured multicast tree and you're reaching. You know millions of nodes, and you want to be sure that every node that's subscribed is getting what they're supposed to be getting, or else that there's some way to to find out who's missing.

F

Someone else can try to contact them directly, but you don't want to keep track of all these things yourself. So you know we're think of this in the in the context of like you know, software update. If there's like some critical vulnerability, you want to make sure, like all the machines running, your software have have been updated or try to track down the ones that haven't been updated and the way this works is there's, there's two phases and the first phase.

F

You join the multicast system and the multicast group, and this is some bad thing where you kind of create a new public key, and you sign some certificate with your IP address and then your key gets kind of propagated all the way up to the root, and what comes back is the hash of some the root of some hash tree, and you can verify that you are included in this join request and then in phase two every time the source sends a message. It gets back a bunch of acknowledgments.

F

Everyone signs an acknowledgement and acknowledgments kind of get combined such that at the root. You only need to basically check one signature or one signature plus check everybody who failed and and has been removed from the system, and the key idea behind this is that it leverages these signatures on on Gap diffie-hellman groups, which are groups were like.

F

If you have G to the X and G the Y, you can't easily compute G DX Y, but if you have some number Z, you can tell whether that's G to the X Y or not, and basically what this, what these signatures have. That's an interesting property is if I have two signatures on the same message and I multiply the signatures and I multiply the public keys. What I get is a new public key that and a new signature under that public key.

F

So you can see you can kind of basically aggregate all the individual nodes, public keys as you're, going up the multicast tree and aggregate all the acknowledgments which are just signatures and then, if there's anything missing, you can just kind of divide out the public keys of the nodes that are missing, but you can also check their certificates to know what their IP address was, and so you can have other people try to contact those nodes too to get the message to them. So again, this was tailored to structured multicast.

F

Can this be adapted to gossip networks? That might be an interesting question?

F

Okay kind of another topic is that applies particularly to these gossip networks. Is how do you? Actually? You know, how do you cut down on the amount of redundant traffic and one thing that happens a lot of blockchains? Is you you're kind of flooding transactions out there, and so everybody has a bunch of transactions and what you really want is for everyone to end up with the same set of transactions, and ideally you don't want- have to send multiple copies of that transaction.

F

So so in these kinds of situations, what comes in really handy is, if you have an efficient way to do, set reconciliation and so kind of so there's kind of obvious ways of doing it.

F

Using hash trees to to you know, compare which parts are different, but that doesn't work if the differences are all over the place or error correcting codes, if there's small differences, but about well I, guess, like eight years ago now, there's a really neat way to do this that we're actually the amount of network traffic that you send is only proportional to the difference in the size of the sets, and that is the idea was that you use these things called invertible bloom filters where, instead of just a bunch of bits, you keep counters that if you set a bit multiple times, you keep the counter, and so what you can do is you can basically take two invertible bloom filters and kind of subtract, one from the other to see which and then that creates a new bloom filter for just the things that are different between the two sets and the other.

F

You need one more trick, which is you need to kind of estimate the size, the difference, but you can do that by doing kind of like log many log, many bloom filters. So this is a pretty cool idea which might come in handy in these systems and then, finally, of course, since, like at least my interest in doing this is to get a good, multicast layer underneath SCP this question of, should we be leveraging some of what some of the kind of trusts decisions that people are already making for SCP and just to remind people.

F

The way SCP works is that it formed quorums in a decentralized way by individual nodes, picking these quorum slices, who are the set of people that they don't want to be partitioned from? Basically the people they want to stay in sync with and then SCP makes sure that that applies transitively. So every node and SCP takes a set of form, slices, QV and and and then a quorum is defined as a set that contains a quorum slice of every one of its members right.

F

So so one question is: could you maybe subscribe only to the sender's that you actually care about, have multicast groups, or maybe not even a multicast group, but some way for you to hear only about the people that you care about? But you need to care about people transitively like if I say you know, I'm only gonna agree to something if Dirk doesn't he'll only of grief, Melinda does then like I kind of depend on her I need to get her signatures.

F

The other thing is: can you maybe leverage the trust that people are expressing in their choice of quorum slices? So in SCP already there's this leader selection algorithm? That depends on slice weight, which is the idea of how many? What fraction of my quorum slices include this particular node, and that give some indication of how much I trust that node. It's not great, because you're kind of flattening this much a lot of information, that's expressed in the quorum slice into kind of, but this one number, but it does provide some indication so so kind of.

F

In conclusion, I think a very large number of the kind of interesting protocols that could come out of this working group will actually end up needing some kind of message. Dissemination system and it'll have to be efficient and scalable to many nodes. It'll have to be obviously self-organizing not depend on a central authority, and it will have to be Byzantine fault, tolerant because you know otherwise the the systems will end up being being vulnerable.

F

Currently there's. Basically, this big trade-off between like yeah, you could make a secure one in which you send a whole bunch of redundant messages. Like everybody sends everything to everyone, you try to make it scalable, then it suddenly becomes vulnerable to eclipse attacks and stuff.

F

You know: we've got kind of individually building blocks for for efficiency and scalability, like dhts peer sampling. You know biased peer selection, things like that we've got building blocks for security things like path, verification. You know, monitored I, get monitoring the act compression quorum slices, but we don't yet have a good way to to like combine to achieve like all these good things at once.

F

So you know I think this is like an important open problem for the kinds of stuff that we care about here.

A

Cool. Thank you.

A

That seems to be like a really useful survey. I'm sure people must have questions and comments.

D

Or anything stand in terms of your own work and people working on this did say something you can bring us.

F

Not yet I guess I want to work on this. It's kind of where, like you know, if I got requirements or said like you know, if I got a sense of requirements of them a guide, what I, what I'm thinking about.

B

Hi Mauricio same on 30 MIT I'm, on the side of the room when I go see nobody um actually when in MIT you had done a peer-to-peer video distribution network based on peer to peer, well, peer distribution, adding FEC to it. Actually we could actually get some kind of I would say low-level security just by doing some short encryption on the FEC headers. And if you didn't know what this key was, you couldn't record anything else and it was really really good to send messages across the network yeah. It.

G

B

Like I would say a coded type of DHT, but it was really good, but it was not really really secure. It.

F

B

A good way to distribute stuff really far.

F

I think this security are talking about is confidentiality which I haven't even touched here, like I'm, actually just worried about availability, okay,.

B

Because I actually would be something interesting to investigate. Yeah.

F

B

The context of this group, because a lot of time you may need to have I, would say some low-level privacy or low-level security.

G

B

The stuff you're sending you may not need to have very high encryption problems that actually will just increase the latency of your distribution. So maybe that's something that could be interesting to to look.

G

B

You and I'm going back into the dark hole.

H

Tobias comments from mu, 1 question: 2: have you considered this stuff? The people in the message layer, security group do because they do some kind of group, key agreement, yeah.

F

So again, this is this: isn't that I'm, not even thinking about confidentiality here, okay, I'm, like in the context of Bitcoin, like you, don't need confidentiality, you just need to make sure that, like people can't double spend right and that's the level on which these things are currently vulnerable.

F

So you know, like think about. If we used like a global consensus protocol to do like a new version of certificate, transparency right, they wouldn't even be confidentiality requirements right. It is, but it's its availability or if we use this like certificate, revocation where you need to make sure those revoked certificates get out there. So so again like yeah, we could. We could maybe think about adding that to the like the list of requirements.

F

Interesting, maybe helpful to get a more concrete problem that this would be used.

H

For I'm more thinking not about this and confidentiality more about the techniques they used to distribute the keys mm-hmm because there's any.

F

Questions I saw no I'm, not following that works. Oh okay, I just may.

H

F

Hear how you think that could.

H

Apply just a feeling I'm not so familiar with. Okay, just a feeling I saw it yesterday. I saw your so it's kind of so.

F

There was like this this. It was just work at Cornell. We're like what happened. Was it kind of broke the identifiers space up into kind of these clusters?

F

And what happened was every time someone joined the cluster, you kind of shattered it and like reorganize everything using some kind of like you know, secret shared like but verifiable, pseudo-random, verifiable, random function like thing and so maybe maybe in terms of like organization, if, like I, don't know where my node idea is gonna place me in the multicast tree, because there's a threshold thing like maybe that that could actually be useful, so I should check out if there's so, which which working group is on I mean MLS.

H

Message: layer, security, okay, cool thanks for the thanks to.

F

A

There question just one question for mice: like: have you looked into the combination of ICN and dataset synchronization, so like Indian and partial sync, and these protocols these are for like set reconciliation? Well, they probably do more than what you need for yeah. Yes,.

F

I guess I should check this out and where did those so those are like drafts or RFC's already papers and I.

A

Mean you know they in the end project, okay, so I mean CCN or in the end style, I see em. You know, yeah has a implicit multicast distribution right.

H

A

It has public key base to duplicate behind it. Right it'll be more than you need here, but yeah big acceptors.

F

Admission control through the certificate system well.

A

This, while signing of messages and sits behind this okay.

E

See if I should check it out, see: okay thanks.

I

A

A

Just a quick, logistic things: there are people standing in the back room and I see some empty seats. So if you want to sit there, maybe with raise your hand if there's an empty seat next to you.

A

A

Maybe this one is a bit tricky and the other thing is: where are the blue sheets? Okay, who hasn't signed the blue sheet? Maybe keep them yeah people on the right-hand side.

A

All right moving almost Christian and the goon name system, okay,.

J

Yeah I have the checker well, thank you for inviting me and also want to specifically thank David. He gave half of his material that he gave his great background for I'm going to talk about so I hope you understood most of it I'm going to make my part much easier.

J

So, to give some background just like David said this whole thing comes a bit more mm where peer to peer was invoke, and we decided that this internet wasn't decentralized enough and then a couple of years later, people felt that this was also be too surveilled and what we had always tried to build in more encryption, more privacy. So this new name system comes out of the grenade project where we have built things like distributed: hash tables you just heard about, and gossip protocols and flooding protocols.

J

All of these states that he's mentioned are in there and part of it is being used by the ghulam system now in viet, overall we're building a couple of other things. So if you worried about interfering being broken in europe yesterday, you know I met the anonymous publishing for you in there. You know.

J

Do ipv6 protocol translation in cases hasn't been solved, yet you know and you name system I have to apologize to martine I'm, not mentioning reclaim ID on this slide yet so we also have identity management on top the new name system, which again relates to the next talk, I hear so lots of other things in there, but today I'm going to focus on the good name system for you, so our motivation is basic and when we build a new Internet DNS isn't exactly what you want to start with for naming.

J

We have this problems with traffic amplification with censorship as mass surveillance, cyber war and aren't we didn't want to go for the band-aid solutions. You know DNS over TLS or something like that. So do name system first thing is, we said decentralize, so no more hierarchy. So just a big disappointment for some of you. The names are not necessarily global. That doesn't mean we can't have a consensus of basically saying: ok, Stefan gets to run dot fr for us. You know that's, ok.

J

We just have to put into our configuration his key and then we can. He can control dot fr, but in principle anybody can, you know, run their own root zone, so you can think of this as the extreme version of hyper local, so hyper hyper, hyper local, where you have euro zone on your machine, but you can of course, delegate or fr to Stefan and yeah yeah. You're very well comes different, I think you're doing a good job on that one we can still have global, unique identification.

J

So if you put in a public key as a name- well, that's the global, unique identifier. So we distinguish between identifiers, which are things we can't remember and names like you know: I can remember ethnic dot, F R I can't remember Stefan's GPG key too complex. That's an identifier!

J

The bigger difference is the biggest difference to DNS is we have query, end response privacy. So, as you'll see, when you ask a question to the new name system, the infrastructure, the even the server that stores the answer- doesn't know what the answer is or what the question is they cut it's encrypted. They can't see it. They can just say well. This is the answer encrypted to your question.

J

I, don't know what you asked for I, don't know what the answer is, but here's what you won't want it to have and then you can decrypt it all right. So it's much better than TLS. If you do TLS in the DNS context, the server at CloudFlare can still see what your question is. It can still know what the answers, in our case it right, but it can't verify that this is the correct answer to your question.

J

Now you might say how's that possible. What we'll get to that so the result is we get also public key infrastructure or signs so DNS, SEC plus plus so to speak, and we can use this for energy management and best of all, it's interoperable use. Dns we have a proxy DNS to GMs, runs on port 53. Who can send a DNS queries? You get DNS answers back, but internally it may use the GU name system for top-level domains that are configured to use. Dna gns should mention.

J

This is a joint work with smart, Johnson bar, so other parties to be blamed or in the room. Don't just beat me up mattias box and Patrick Guerra, who couldn't be here now I've always been told. If you won't get anything out there, you have to make sure it's usable, so I'm gonna start with the user experience site, so here's zone management. Basically we have a graphical user interface.

J

You can also do this with command and if you prefer, where you can enter record so, for example, here I'm creating a new zone, I called it RMS for fun and then, where I created a new zone, you see you know, there's the public key for that zone and I'm gonna go here type in the name like new, give it a record type. So we have supported some of the canonical ones in from DNS in our user interface and then some new ones for the new name system.

J

Now I can type in you know the usual information I can type in an expiration all right and add TLS a records for that, for example, I can go and type in here the domain name and click connect. Then it will do a TLS handshake and obtain the TLS a record automatically for me so somewhat easier than what I'm used to is most DNS software and then I have, for example, here the a record in the TLS a record for ww in the zone.

J

What that happens is basically I have my zone. You know, Bob has his on here, but and once he's done this he can reach his zone under W, dot, Bob or, in this case W dot. Rms I have my public key I need to introduce myself to other people who won't have a secure channel. So maybe I go to Stefan, who is running, but if I go and tell him hey. This is my public key. Please put that into the zone file delegate this domain to me, so he would put he's no Alice, sorry Stefan.

J

He would put you know my name into his own Travis, my public key. So that's the equivalent of the NS record in DNS, alright, so in DNS he would put the IP at well the host name and the IP address of the authority. In our case, you just put the public key. Alright, so a bit simpler, you don't have to teach people about glue problems. You know much less work for Stefan. He just puts a public.

J

He'd only has to put one record and once he's done, that the delegation works, and you know Alistar Bob, Dobbs, w-w-which delegate to my website. So how does the name resolution work? Well again, we have the two parties here: Bob has his own Alice has hers own and Bob will periodically put the information from his own into a distributed hash table.

J

If you remember where that was from David right, key value store and our case, we used a 256 bit space, not 160 bit space, but that's okay, underlying it's, a variant of Kadeem Leah, so he'll be also happy with that right. It's a very because we do some randomization to get around a couple of the Eclipse attacks a bit, but it's close I don't mean half the log logarithmic performance, logarithmic connections.

J

All of that is there so no worries she has ever, and so he put this information into the DHT and when Ellis wants to figure out who is dubby dubby to Bob that Alice well, she first find out well who is Alice who's Alice. She wants to well, she knows she's Alice. She knows Alice's in her DNS system is not DNS, so she goes and finds in her database Bob's public key when she goes into the DHT.

J

So good thing, there's a local cache goes from the DHT and says well, I, don't know what this you know: ww under Bob's public key is and gets back the answer from the distributed hash table to make this practical. Here's how you can do it. Here's the mozilla firefox' you go into your preferences set network settings set a proxy for socks. Proxy may show you a proxy DNS when using the Sox, otherwise it kind of doesn't work and rollout.

J

You can do wwr, MS or something like this and resolve the names, and you can see here, it's verified by new, alright, no longer, let's encrypt there, because the men in the middle TLS proxy has basically verified the certificate of the website against the TLS, a record right.

J

Finally, TLS is working for everybody, you know and but then synthesize a new certificate against the web browser saying yeah. You trust me as your proxy and I verified. So now it's being verified by the ignore name system for you alright, so this is actually working. I should mention this whole manual configuration Martinez made obsolete by having a little plugin in the browser where you can kind of say, just configure it and able it and it should be way more automatic in case this was so difficult.

J

Okay, now we have a little privacy issue, of course, in security issue. If I just say: okay I'm going to put this information to the DHT, everybody goes and says: well, ok! Now how can I trust this DHT? Basically, instead of being able to have any DNS operator, modify the answers and monitor my traffic? Now I have a billion peers in the DHT that can do the whole thing. It doesn't really sound like a security gain here so I'm. Sorry, we have to get to crypto I'm going to try to do it slowly here.

J

So in crypto we're using elliptic, curves so phonetic curve. We have something called a generator. We have the size of the group all right, so that's some number n, usually a prime, should be a prime number and then we have a private key. That's just some scalar modulo N and then the public key is basically we have an on the curve, the afrinic operation to add points to themselves and, if I add GX time to itself I get another point.

J

So point addition gives me a point: let's group operation and so the point P is defined as adding GX times to itself and that's then, the corresponding public key to the private key X, and basically the security assumption of the elliptic curve says that it should be very hard to get X from P. You know, G is public, everybody knows G, everybody knows n and all sorts of other group air. As long as you don't know, X you can't kind of do P divided by G. That's the hardness assumption! I can't do it.

J

Okay can't do this efficiently, I should say yeah. You know two to the hundred twenty-eight operations and yeah fine, it don't do it. So this is just me. This is nothing gns specific. This is just you know any usual lip to curve cryptography that hopefully you're somewhat familiar with. If you're not. You know, just trust me that this works and it works pretty fast one hundred thousand CPU cycles. For the point multiplication. It's not crazy, inefficient.

J

Okay, so now for the DNS side, if you think in DNS terminology where we have labels all right, so these 63 things between the dots and DNS now I'm going to interpret those as a number modulo n. So if you say well, but www isn't a number well hash should modulo n and you have a number right.

J

So that's why Kornel they label and then in the end, we still want to publish records and we basically said we're going to do DNS compatibility by saying if the record type is below 65536, it's a DNS record type and we're going to have a 4-bit field. So if it's above that it's a g, NS specific record type, so the DNS people can continue allocating record types and there won't be any conflict with ours, but so we have record sets set of records.

J

So this is, you know: IP addresses, TLS a label records whatever else we want to publish in there- and this is just in the clear text in the zone under the public key P for the label L. So every zone we don't log I, add a five as a domain name. We identify the zone, it's a public key, so the public key tells us which zone it is every zone must have a public key, just like in DNS. Every zone must have a so our record okay.

J

So these are the in clear-text records in the zone P under label L. Okay.

J

Now, when we want to go out there and ask the DHT for information or the DHT looks of things by a hash, all right, so we're going to ask called the hash that we're going to send out for the DHT to query for records the query hash so Q for the public key P under label, L I'm, not telling you how you could get this here's I'm just saying this is what we're going to send out to the network right to get this information and what we're going to store in the network in a good form is what called a block a block of information.

J

Dns is strange, 512-byte limitations. In our case we said: okay, 64 kilobyte is the max. You know seemed reasonably sufficient number, but maybe in 20 years they're gonna tell us. Why did you only pick 64 kilobytes, but it's not supposed to be for publishing files as possible. She metadata right. So we have the encrypted information phone able L in zone P that we're going to publish under QP l that we're going to call so this encrypted things. We're gonna call BPL right. So that's what everybody can have it's just encrypted.

J

You shouldn't give any information from that. Okay, that's the terminology! Just so you know what the various things mean: okay, so how am I gonna do this? If I want to publish the records, you know, I know them in the clear Texas RPL all right, I'm going to first do the hash of the label and the public key.

J

Once you take the label in the public key hash. Those two together call that small H, that's a number and then I'm going to multiply that number of it's, the private key of my zone. Remember X was the private key of my zone, so much multiplying two numbers gives me a number mod n, and that turns out to be is another private key ID is still a private key, so I can derive one private key from another private key now notice. D is literally any private key.

J

If you don't know what H is and if you don't know what L and PS you don't know what H is. You know you have no relationship, there's no clear relationship. If you want to get D, you need to know X and you need to know H all right, so D is just as secret as X loss.

J

Okay, so now I'm going to do is I'm going to take my records and I'm going to encrypt them as symmetric encryption, using an encryption key that I've derived using a hash key derivation function, so fancy hash function also from the label and the public key. So if somebody doesn't know the label and the public key somebody is not able to do, you know, enumerate the zone, somebody doesn't know the zone public key or doesn't know the label either one of the two conservers the secret. They can't decrypt.

J

This agreed a symmetric encryption is a key. If I don't know what the inputs were done. Okay, so when I encrypt the records was that and I'm going to sign it mister d and I'm going to attach DG, which is the public key corresponding to the signature, just like exchange? What's the zone key now of DG public key of the signature, that's the block and I'm going to publish this under the hash of DG.

J

What does this mean? Well, if I'm in the know, I'm a DHT node I can check that this BPL should be published under QP, because I can check the DG hashes to you know: H of DG, that's very trivial operation and I can check that this signature matches this public key. So it's a well-formed record now, if you are not in possession of the X, you can't create this record.

J

So I also know it comes from some zone, but I cannot figure out what the zone is again based on the security assumption of the elliptic curve. I can't divide this DG by P, so I cannot know, you know what the label is or what the public he was or what H was I can't even tell which zone this record belongs to alright, so I have to be neutral infrastructure.

J

The DHT can't know for whom its publishing records it doesn't know what it publishes, but if it returns these things well, anybody can check and if you know Stephan gives me a wrong record and I go and save its difference. You check the signature right now. There's one thing we do put in the clear text to that I'm kind of omitting here, which is there's a time out value. I can say this thing should only be valid in the network for whatever two weeks, all right and then afterwards everybody should drop it.

J

But this time I value is really not security. Sensitive! It's more. You know housekeeping now, if I want to search I, don't have the private key but I'm assuming again I know the zones public key, remember: dot FRS in my root zone, so I have the public key of Stefan in my keyring. Maybe gotten by default is my operating system. Just like every good. You know, recursive resolver has gotten some trusted root zone, so I have P and I've guessed. The label is ethnic. Somehow magically knew that one. If I don't have no chance.

J

If it's a password, you know yes, just give it to me so that we have access so I know the label of the public key, which means I still can come. H of L and P. So I can get my small H and now comes the magic really complicated magic. I can compute H times P right on the hash of that which is the same as H times X times G what he was XG very complicated math here and then this is the same as H times DG by definition of D right.

J

So I get the same query right. H of DG study was published under I, can compute H of hash of HP, so I get the air can ask this question and of course, I can check the signature myself and I can do the decryption if I know the public key and if I know the label, if I don't know either of the two I get nothing I can check that this is the right answer. I can't decrypt it.

J

So, basically, the only way to get information out of gns is to know the zones public key or end the label and of course, I can known public he's over queries for other zones. First, so I have query privacy response, privacy and signatures in the system.

J

Okay, now we also can have, as I said, global unique identifiers, very simple method. You just take the public key and appended at the end with elliptic curves. Fortunately, that barely fits into a label. You know, so we can just put a public here. At the end, we have a global, unique identifier. Just nobody can remember it, but if you do need this in some kind of application, where you're going to say I need global uniqueness.

J

Well, as long as you don't expect users to remember these things, you can just from something like Alice to Bob Dodge public here and it works. We also worried about key revocation so for a vocation. You basically sign this with your private key. This zone is no longer valid. You mentioned flooding earlier. You know we flooded basically over the links in the p2p network over the DHT and other things. If you have more now, we use epstein efficient, set reconciliation.

J

You mentioned that earlier for peers, being all fine, if somebody reconnects and has missed some floodings, we use this efficient set. Recon see a shinto kind of get the mystery box across to prevent the ddos potential you mentioned. Flooding is bad for details. You have to do proof of work calculation. You mentioned that as well before you can revoke your key. So basically, if somebody just goes, I'll make it public by keeping revoke it, and does this 100 million times well.

J

They could also just mind Bitcoin instead and we try to basically make the cost of doing a revocation CPU wise expensive enough that this is not effective day. None of service vector, of course you can do the calculation ahead of time. So if you're Stefan you're running, but if aren't you go and say if I'm compromised, I can't just say well, I have to wait a week for a week for computation before I can revoke well just make your proof work ahead of time and only then go live mr.

J

dev our Stefan easy to do umm yeah. Of course you can store the relocation stuff offline in case you don't want to be hacked and have his own reverb accident. Okay, so location is in there now after. Thank the IETF for the more recent developments, so actually we had proposed to use dot canoe as a protocol switch right and as boring. He observed this is how you should do it in his RFC, but, as I said, he's wrong here.

J

You know we asked the IETF, please reserved canoe and following the usual IETF way, they didn't follow their own process, and so we decided to okay if we can't get out no we're just going to take everything. So the latest implementation that we have released basically allows the user to override any domain name with the new name system just put in the public key that you want to have for any domain name and it will go to gns instead of dns. So we no longer looking for this.

J

Is this endless canoe and the very nice effect was. We did the usability studies and the users love it. They can't even tell they're not using dns anymore right now, it's application developers. You may not like it so much right, but for users you know it's great and you have a DNS proxy. So as an application developer, you can also no longer tell if you're, using DNS or gns. It depends on what your network provider or a user has configured.

J

Maybe there is privacy all right, that's a slight disadvantage, as a user I generally like to know if I have privacy, but here it's not completely in transparent and the technical side, we did demonstrate at our DHT scales to millions of records. They would not think that that's the great surprise, but you know you have to do some tuning before you can actually show this.

J

We implemented a new zone import to basically given a list of that if our names hits different servers until they give us all the information because, but if does not allow zone transfers, so you can just brute force it. If you have a list of names very strange that they publish the list of names, but don't allow zone transfers far. So you have to ask for every single one.

J

What's the DNS information we also implemented ascension, which is a tool that does proper zone transfers so slightly more efficient and use that to import CSV and dot bfh dot CH and made sure that basically, all of the record types we found all of these three small zones are supported by our system.

J

Ok, so to conclude, DNS monopoly is over. Gn is simpler than DNS, no more. You know and SEC 3 no rr6 are required. We have private name resolution censorship, resistance. If Stefan blocks you I can just put your zone in directly and I'm fine, we don't require I, can or root zone or I on a special use. Tld. You just take everything and if you previously saw what the goo name system a told people, if you see doc, knew that special forget about that. Now teach people about that.

J

There could be other protocols and DNS for name resolution, and they just can't tell, and if you want to get your top-level domain and your member of DNS up, you know we welcome your donations. Just like I can well consider donations it'll help us scale our infrastructure. Thank you. Alright, thank you.

A

Are they any questions.

F

Yeah David yeah, can you say a little bit more about how adding a little bit of randomness for its the Eclipse attacks? No katemel.

J

Yeah, yes, so basically, what we do is be first to a random walk over the peer-to-peer overlay Network and then start the Kadhim layer. Let's say gradient descent agree.

J

You cancel absolutely wrong I'm, not saying you're solving other problems. You talk solving specific Eclipse attack problems. That way you.

A

J

Similar tax, if you have a very large number of Sybil's, are still a theoretical issue: don't okay in practice, going to have that many Sybil's, especially once all of the DNS operators run G and s DHT notes on their fat. Dns servers. That's my hope, but it's addresses some concerns right. So you do this random walk first and for the random walk. You need to know kind of what the sizes the network is.

J

So if your network size estimation algorithm, so we get log n off the network size and if you do log in helps in a snort apology, you know you had a random starting point and thereby- and if you do this every time, you do a query and you do it repeatedly. You can start from different starting points and you end up. You know different places possible in so civil attack becomes less effective. An eclipsed attack becomes less effective.

D

Reminder and to identify yourself at the mic, hi.

G

You know my question is about what would be the information you.

A

G

A

G

Be it should be, my name is severely okay. So my question is: what would what would be the information inside the key if the tool Nords are running in the cluster right, so the active node is got failure so how the second node, with the key I'm not.

J

Sure information that he aqui is just the public he or private key or not short here actually.

G

The machine is running this okay. The zone is running on the machine right if.

J

You're running a zone, yeah you're, basically taking all of your record sets and you periodically publish them in the DHT in an encrypted form. Okay right, so even if you go off on the DHT will cache that information for some amount of time is that help.

K

Giovanni si DN so I'm also research around DNS, guy and I work for an operator, so I have to disclose that rmisaac said about CEO name is systems, and but my for me, like TNS, it is not just in your name system, but the real thing of the DNS is about high availability and high performance and Kim delivers is not only the name system. That's very important.

K

If you want to propose something, you need to do what you're doing but I think a real enemy or should be something that you can deliver high performance availability that DMS can deliver of anycast replication cache in a modular stuff and.

J

Trust engage rest of the people, of course, but you know caching, we can do in the same way. The DHT caches records, intermediate nodes can cache records and dhts can be high performance and, unlike DNS, we don't have problems without of bailiwicks, so you don't have as many of me directions in our case. Caching is also implemented, the client-side right so an end-to-end site, so we can have possibly, if you have frequently used names, they might already be cached locally, so so caching is still considered in the system. In fact, we have some additional features.

J

I did not mention like when in DNS you have to you time out a record. You go down to time to live zero, then kind of all the caches become stale have to drop all the records. In our case, you can already tell in the record set hey. This record is going to be valid after a particular point in time, so you can I can pre-populate caches this information that will be valid in the future ahead of time. Yeah, which is something DNS cannot do so.

J

We've got some features to actually do better in caching than DNS yeah.

K

J

Wise I don't see how we inherently are worse, but of course we do inherit the availability and performance properties from the DHT, but the H trees aren't necessarily super.

K

Slow, so maybe it's for exercise for your folks for next I mean continuing this work. Would how would you compare if you would run that comb with more than 100 I mean if you would run calm, which has more than 100 million domain names on it? You know, delay allows for dynamic, updates and there's very fast response time. So maybe something you want to consider.

J

We mean one of the things we have seen is in terms of importing large zones the most of the churn we studied on as efore, that is in the are our sick records, and so since we don't even have our our sake, records most of the churn of DNS system won't even touch us and the import cost primarily for us is doing the signatures and well, if you have DNS SEC the signatures you use, there will be more expensive than EDD as a signature we use. So there again don't see a problem with significant updates.

J

Of course, if you have things like gin DNS, we have people /, changing the IP address every couple of hours, that'll be hard RS, the DHT I agree, Thanks, and one thing we also can't do is using gns to do things like configuring. Do H, / DNS, so that our power, reverse lookups, don't exist in our system just quickly. We have.

A

To close, the line have the this.

I

Is official from the Swedish internal foundation? We of course happy that you use the resi for your tests and but I would know if I, let's say I would like to go to the IETF website using the DNS. Then, if I understand you correctly, I would need the ITF public key first.

J

Know if you have the public key of dot-org and don't work, has the public key of ITF. It will still work fine. Well, then, I have not the public key of the door right and if dot-org supports gns, we would of course put this into the default configurations just like he would do his hyper DNS and everybody tell who the darks name servers and IP addresses are now. If you go and say not, org does not support g NS, but ITF dot-org. Does you could put into your configuration saying IETF dot-org?

J

Is this public key and basically only slice of this part of the namespace for g NS and leaflet or cos dns.

I

Okay, that's all.

J

You start where again sounds almost hyper.

I

Hyper dns, hopefully, that you suppose that we would make another central organization to collect these public keys that you won't reduce to betray everybody. We allow.

J

You to automate that process, because we have idea of didn't sorry curve DNS. We stole that from them. Basically, if you call your name server, something it has a public key noir format in it will just say: ah that's your public key, so we can kind of steal that information. If you provide it Thank.

I

L

Wes hurt occur, si0 hats on my head at the moment. A lot.

B

I have a lot of them that might.

L

Relate but really cool, math I mean I. I. Think that the math behind this is is really slick, and so my question is more about especially the screenshot of the web browser showing the RMS page, for example, and the usability of how you might get there because yeah that one. So if I'm understanding this right, there's sort of this new global collection, where you might have a whole ton of essentially I, don't want to calm roots there, public keys and under which there's a whole bunch of names.

L

Yeah and you're gonna collect all of these public keys on your system and maybe there's hundreds, maybe there's thousands, maybe there's millions. Maybe we each have one which is really kind of close. It is everybody should have one, but you don't need to you know.

J

You can't have global names which are kind of like the consensus. We all agree that we put those into our configuration and then there be local names, so maybe I put RMS into my configuration, but you don't and then we can't use the RMS names as global names. We'd have to do whatever wwo RMS new org right, but if I go and say well, you know I I like this website, and it has been censored by my government but I have its public here. I can just put that in and bypass this censorship operation.

J

L

J

That brings me I, don't have both.

L

We have a right so I understand that. So that brings me to my question because there is no definition of a global, a global name. You sort of stated that actually on the first slide, don't go back there, but total names comes from global consensus and other questions. How do you you know? How do you get to global consensus? So the reality is. Is that this, the URL?

L

My question is actually related to that URL, which makes it look like you have no notion there of what public key is actually serving that that global name so I mean the reality is as I would expect from usability perspective is not a global name. This is the local name. Is so I have RMS configured on my system right.

L

So as my application level, if I, if I put in RMS I'm gonna, go search through all of my my public keys and look for RMS or near each one, which one do I pick, which one do I get in the configuration you say: dot, RM s equals public.

J

Key you locally, as a user, give each top-level domain name that you want to capture, assign it to a public key and you can have conflicts. We can assign one public key, / top-level domain. You can assign the same public key to multiple top-level domains, the future, so you have to manage that list. Well, I would assume that for the global consensus you get a same default. Just like your network service provider gives you a same default for the root zone. I look forward.

L

To that consensus process, oh.

J

I assume we will descend on that so.

M

One kumari Google also speak without any hats. A couple of things: first, your URL at the end, unfortunately, is incorrect. I think you need to add.

B

M

Find it yeah. Thank you um so I understand that kind of part of your design goal is to not have a centralized system right. You end up with the consensus based thing: let's say that arm RMS ends up being a consensus, global name, um that's really great and everybody who's using the DNS system can use it. What do you do when, for example, the other users of the namespace, like the DNS end up trying to use RMS as well you're going to end up with and/or?

M

We generally would say we advise I can to not assign.

J

Any more names maybe told the same thing: IETF.

B

J

And so now the advice is the other way around: okay, any name they might assign from now on, it's likely to be a conflict with some user. Okay.

M

That's a perfectly fine answer. Thank you. I had a third point, but I don't remember. It was anymore.

M

A

Was fun? Thank you very much for bringing this to us. You're welcome one minute to set up Nathan here's your solution with me.

A

So if you want more space next time be sure to sign the blue sheets.

A

And make my a few slides up? Are you in the queue.

E

So you need to get into the queue.

A

So Layton but I'm getting you on. Okay,.

N

Can you give me okay? Yes, we can okay, agreed. Okay. Can I control my just lights from here? I, don't think so. Do you have to divide it, no worries. No! It's! Okay, hi! Everyone! I hope my voice is coming through. Well, yes,.

A

N

Right, great, okay, so um I'm Nathan from Singapore and today I'm presenting on dissent in agreement protocols for large-scale decentralized identity management. So, let's go onto the next slide.

N

All right, okay, so to just give to just give some context in the last I eat here: presentation in Bangkok I share on how decentralized identities you know it says. Ice in short, could help address the issue of data breaches and the challenges and constraints right. Of course, the details are over there. This and you can see you can find a link over there. Vish nama. It goes to the last presentation that I had okay, so we talked about scalability. We talked about privacy protection. We talked about interoperability across various decentralized platforms right.

N

These are the things that we discuss for very high level and some of the possible solutions, perhaps so in the next mix like.

N

Okay, okay, so this is my brief introduction, I'm research engineer with one of the local banks in singapore- and this is my background. I see on the I pleasure here- are season four five lions and work with the global focus on on some of these chain solutions right. So this is my profile, can access it? Okay next slide looks like this okay, so one of the things that we have um we have identified myself and my team in stem for any large-scale cross and polity centralized identity management.

N

Three attributes are necessary and you know this is called you know in in in in popular terms, right the blockchain trilemma right it has to be sufficiently decentralize, ie, bottleless and, of course, caleb on a planetary scale. Imagine embodying billions of people onto the top chain right identities right and, of course, he has to be secure. So this is the trilemma I think most, if not all guys who are privy to to the to the decentralized space would know right right. So this is the trilemma.

N

You can only choose to write either scale a beauty and security. Osgood became decentralization right. Okay, next type, this.

N

Looks like okay, so um yeah, two quadrant Vitalik bittern right, locking systems keone and most have two of the following three properties: right right: it's gonna be decentralized or skills. Began security looks like this yeah. Okay, alright,.

B

N

The last from the last presentation in in bangkok do now. There are many many promising developments which were ongoing, then and still ongoing, and you can see on this night.

N

You know a cosmos, one of the interoperability blockchains have so-called mean net has launched and, of course, you have IIF this centralized at the foundation extremely promising many organizations involved in it and coming up with the D IDs, and you know the overall solution architecture for for this centralized attacks, platform right and, of course, al-quran and um a very promising doctrine protocol right, which promises to achieve the three of three of mention points in skilled IT, security and and and and and decentralization right and, of course, vote.

N

You can see many of these noobs are offered so in in my room. My role is to explore how these developments right could could help and how my organization could in time right do to to to to to to be on board this whole decentralized identity, movement right. So next, like this.

N

Okay, so this is a sample view of a decentralized identity ecosystem. Today, I'm going to talk about the one-sided theory right you can see. This is the one of the sample view proposed by Microsoft right of the decentralized identity ecosystem. You have two people apps and you have a D ID, a complication which I'll talk about briefly later on, and then you have, of course, the decentralized platform, the blockchain suffering. So how do we achieve scale and then on the decentralized here?

N

Is the question that you know I hope to share with everyone today right through to improve for the slides right, looks like.

N

Okay, so um the idea is, you know, harm at a superficial level. The idea is simply a new type of doubly unique identifier, URIs right by a deeper level. The IDs are the core component of an entirely new layer of decentralized secret identity, a public infrastructure for Internet. This DP key I could have as much impact no on cyber security and privacy as the development of SSL TLS right, which we have today so example the IDS is shown over there. You are n UUID and, of course, a namespace I know for some of the IDS.

N

It could point to the ether and blockchain or the Bitcoin blockchain and a user can have more yeah this and, of course, the IDs are not limited to an individual object, can also have a D ID right and I go t device and in turn a stinky bass could also be could have at the ID attached to it. Okay, so this is the ID enjoy. Let's go on to the next night.

N

Hey looks like okay, so how is the room is approaching the hole this this wave of the centralized identity solution is true. The various ERC right, if the request for comments you have your digital identity, agreed that, like with identity, er c720, you know since I'm, two five of which I'm part of it, and then you have multiples my contracts in short right, which was speak each other right, but claims identity, claims and so on. So forth, looks like this.

N

Okay right, so um what we have identified is that, of course, you know, I think SS what everyone would know we have. We have a scalability concern within the room. You know with all the different role, also Constantine and Paul, and alright still be these- do something that everyone is grappling with right, so I'm that many ways to achieve the same post with different trade-offs right correct. So this is a quick summary of of some of these some consensus algorithm right now we have. But what captures our mind and imagination? Is the sensing equipment right?

N

If you can see the visited agreement right? This protocol is a as a protocol in which users are privately and suitably randomly selected to participate in committee to execute one step of protocol and the privately select. The committee members then work as a message which includes their proof of selection, followed by a consensus procedure, and we believe even myself, you know Mike II mean I. We are convinced that this is a very promising development. This presented agreement could hold the key to the future of this decentralized here for the identities to be stopped.

N

Phoenix, like this.

N

Okay, okay, so um you are Guren right now overview, visiting agreement right, so there's some challenges which this policy to address number one is to avoid a cyber attacks. When you know somebody impersonates and FS re impersonates or no, it creates many identity to influence the recruitment protocol and, secondly, ask you to millions of users and being resilient to denial-of-service. Ddos attacks right now continue to operate even if an adversary disconnects of users, true, never partition or whatsoever right.

N

So this techniques right and accordingly, in this in this white paper, you could read I've provided links over there, I'm very, very good at mathematical rigor and in this studies right with the users right now, through the use of with users, a Goran assigns a way to each user, and then this beam is designed to guarantee consensus as long as a weighted fraction, a constant greater than booth of the users, honest second consensus by committee visit leader.

N

We may achieve scalability by choosing a committee right and it's completely random and the crypto graphics, so audition right to prevent an adversary from targeting company members. The good protocol selects committee members in the private and non interactive way mixed like this.

N

Excellent ok, so this is the very high level, of course, on the mathematical formulas could be extracted in the in the white paper itself in the in the academia, academic papers itself. Right so using this vrf right, very verifiable, random functions, one is able to ensure you ensure that a subset of users are selected right completely random, to ensure the to ensure that this bunch of users, in complete agreement on on on on on validating the transaction right. So mix like this.

N

So, in summary, we believe my team and myself. We believe that visiting agreement is the foundation.

N

The protocol is the foundation they for any decentralized platform, decentralized use case to happen at scale right in a secure and in the sufficiently decentralized manner, and- and of course, you know with all the developments in this space, we are keeping a keen eye, my team and myself in Singapore they're keeping a keen eye on how this what are called the development this protocol right can help anybody else trying to be to be part of this global decentralized identity platform right to be part of this platform right in the future right- and it's like this okay, so this is unsound, the best medical um in the in the previous session, there was a in the previous session.

N

There was about mathematical from this so yeah. If anyone is keen to get out of the nitty-gritty of the formulas, they are easily accessible in in the links provided mix like this ok di F, again very exciting. A lot of architecture been discussing alright next time.

N

Okay, so this is my contact details. um You know um feel free to hit me up and we could discuss more on the centralized identity platforms and Byzantine Agreement pop course questions. Anyone I think. That's all.

A

N

Anyone interested in the centralized identity, gyro and so there's.

F

One worth in this piece, just a quick note in terms of our IP, are mostly.

B

F

I'm David was Aris from Stanford might be. We might need to note that I'll ground this patented.

D

Presented here so it's.

C

A

All right, thank you very much Layton, so we hope to meet you in person in Singapore and later this year,.

N

A

N

A

All right so we're coming to our final presentation.

O

Okay, hi everyone. um You may have seen the earlier in the week. I turned up another research group on here again still a spooking next-generation, Internet project of the European Union, so I'm involved in one of the the open call projects I'm going to present today, but there's a there's, a four other open calls. It may be of more interest to them. The one I work on, but actually this is now slowly falling.

O

Do this okay, so this is a call by.

O

Foundation to have you work for the internet, so this is a project in total at at the moment, there's about 20 million euros, that's going to be on offer on various sized grants, ranging from 5,000 euros through the two hundred thousand euros, depending on what what you're working on, and so we hope that. Well, you are here building these sort of next generation of Internet and we want to focus your attention in in some particular areas, so internet foundation and Gartner got together.

O

They were asked by the Commission to do this study to work out what will be the vision for the next, a generation of the Internet and actually to create an Internet of human values, and so this this study and this document is available online. You can go to where ng I got a you slash vision.

O

They went through a consultation process. You can't really see these this graphic. This is really for information. The the readability is not there, but it created this a big topic analysis of different areas. Now, there's a pre ng I, a process going on, which is what I'm talking about and then there'll be further ng I projects happening in the not-too-distant future, so the consultation involved, a larger ecosystem I'm from giant which is the association of research networks in Europe.

O

It also involved the domain name, registrars ripe ncc as many organizations as they could vacuum up that they thought would have an opinion on the development of the internet or a future internet in this space.

O

In one of the topic areas that brought up it was engineering trustworthiness and actually the decentralized in an internet wide-eyed. Any mechanisms which something presented here are part of that of that space and an interest to be covered by by this funding program. And so you know why did I come to the decentralized internet infrastructure research group? Well, actually, the the trust, management and identity management components are of particular interest to me. We a giant, run and Identity Management Service for research and education called edgy game.

O

It's an inter Federation that connects the identity Federation's that exist often run by your local research networks and there's some work on resource discovery. That's presented in another open call, so some of these areas are interesting to me: will will the work that I've been doing for the past decade become extinct as a result of changes in this space, or how do we do the transition between those systems or this cold? You know coexistence of a future identity infrastructure as well as what is but in place at the moment.

O

So there's some internet of human values requires not just down the underlying means of infrastructure, and some people believe that this infrastructure needs to be entirely replaced. Other people are building layers on top of existing Internet infrastructure, and so both those um thought patterns are being covered right. So, if you do have what some may regard as very crazy ideas in the initial stages of ngi, they are all being explored because we even even I guess the initial proposition of the internet was crazy at some point in time right.

O

It's just now so widely deployed that we just trust that those decisions weren't crazy at that point in time, because you.

B

O

Unfolded to be to be accepted, but these these pillars that we want the future you know need to be built on. You know touch some of your work, some of your research and and so there's a range of open calls that are happening right now, for in total, you can visit NGO dot EU for more information, there's actually a very short deadline if you're interested in the search and discovery of ngi, zero discovery or the privacy enhancing technology project of led by a no net foundation.

O

That's an April 1st deadline, it's really really soon, but for privacy, enhancing technologies, NGO trust, which is the project that I'm in the consortium of our deadlines, I, April, 30 and the distributed ledger technology ledger open call also ends April 30, so you still have some time. I got questions before some people said what about the rest of the planet? How how European focused?

O

Is this and there's actually two specific projects that are working on eu-us collaboration, to make sure that an internet, our next generation internet, obviously has to be for the planet not just built only in Europe? So the focus is partnerships with European organizations and the.

O

Associated countries, so they can directly I get funding and there's more. If there's more information on the Commission website on who those exact countries are, these particular programs are targeted at you, us collaboration, so it's best to work with a partner. You may interject, if you want only one okay, so there's a specific program for EU us, but best to form an Estonian e-business.

O

Look for partners in in Europe to work with in order to be sure that you get funded, but actually your your proposal has to go to a panel at the Commission to decide on European European this right at the very end of the stage, we're not necessarily going to exclude your applications in the initial reprocessing stage, just because of way of where your resident, and actually it's actually, where your residents not where what your nationality is so Europeans living and working for startups in the US could actually still be excluded from this program.

O

Unfortunately, this is showing the pipeline of future projects. We currently have for running real soon now, search and discovery distributed data and to privacy groups and then there's three coming onboard now.

O

The deadline is real soon now for both visa to coordinate these open collections and so that we starting up later in the year and then there'll be a further tranche of other open core projects that the people who tap onto so these are the ones being with enterprise in 2020, so key characteristics in on that found a run, this search and discovery and the privacy enhancing technologies.

O

One of these open calls they've got money between five and fifty thousand euros available. You can apply as an individual and they recycle every two months. So the fact that it closes on the 1st of April it opens again for another two month window and closes, and this will be a rolling cycle until they run out of money. They have about 5.6 million euros yeah to think about now. At.

J

This point I would like to ask the question: there's one additional thing that is missing in terms of key characteristics here that I was told by an L net which, as a Swiss person, hit me quite by surprise.

J

As you might know, Switzerland is a bit more expensive than the Czech Republic and they told me that the maximum salary could pay to anybody in the organization, broad salary, under this grant or 65 euros per hour, I'm, not sure too many people in Silicon Valley. This is interested to do projects for, say, 50 thousand euros at a maximum salary of 65 euros.

A

Can we clarify.

J

This offline- this is just.

A

Like basically, information yeah.

O

So then don't apply to Internet Foundation apply so.

J

What's going on so Jake, this is a restriction of prior to the other ones.

O

As well, that was my question. No I we haven't, we haven't worked out, I mean it's a it's. A body of work. I know that an element, a very good at hanging up money with very low overheads and getting a lot of value out of that. But some of these things well, okay, let's have this is actually.

D

O

For this one, we also run up privacy, enhancing technologies and a distributed data in in the ledger. Project ledger has up to two hundred thousand euros available. Some of their money is looking at the commercialization and support to turn your ideas into a business.

O

So if you're ready look at look at ledger, you can actually do that now and they all come with support business incubator support to actually get your ideas through a pipeline and actually running a business and hopefully making money out of out of your work in this space within our consortium. We have three three projects where we give you varying amounts of money like a viability project up to a hundred thousand euros.

O

The next two options require co-financing so we'll provide you 180 grand if you can find 90 grand for for the next stage in the development of your project and we'll give you 200 grand if you can also match it with 200 grand for the commercialization of your work, contact me and ask questions.

A

Thank you much book, there's good news for dinner, gee and probably some other IETF groups thanks for the announcement. Okay, we're at the end.

A

So unless there's anything else, I think we can give you back a bit of your time. We need to do sheets quick comment, so if you have any idea for say, running or hosting a dinner day meeting outside the normal ITF schedule, please feel free to talk to us. For example, if you are organising conference or you just want to it's gonna meet in a smaller team, smaller group, let us know, thank you and see you next time.