Opening Plenary
Monday, 8 May 2017 at 2 p.m.:
HANS PETTER HOLEN: So, welcome everybody to RIPE 74 in Budapest. My name is Hans Petter Holen, I am Chair of RIPE, I have been that for the last, three, four years now. My predecessor Rob was Chair for 25 years so I still have some years to go. It's 17 years since last time we were in Budapest, 2000; back then, I was Chair of the local IR Working Group, we don't have that any more, it's split into Address Policy and Services Working Group. We had around 100 people in the Address Policy ‑‑ or in the Working Group room and we discussed important topics like reducing the minimum allocation size from a /19 to /20, and how to do IP addressing in GPRS, that is some years ago. Today, we are discussing what to to when we don't have any more IPv4 addresses again, so there are some tweaks to let the last supplies last longer or maybe they shouldn't last longer, that is a debate going on. And of course, the most important thing on the technical side is migrating to IPv6. So, there is a lot of things going on in the community now, so with this, I would like to welcome you to this RIPE meeting with 658 participants registered so far, and so up until half an hour ago there were 370 checked in, so I see there are still some few chairs available here for the last 300 that will probably come the next couple of minutes.
So, RIPE meetings; this is a meeting, not a conference. So you are not here to be entertained or educated, of course that may happen well, but you are here to participate and engage. That is very important. It's an open meeting, so anybody can participate, and we are bringing together people from different backgrounds, cultures, nationals, beliefs and genders and we want the RIPE community to stay safe, supportive and a respectful environment, and from the beginning when we were 10, 20, 30 people meeting, up until today where we are more than 600, there has been the need to develop a code of conduct, so the RIPE community now have had a code of conduct for the last couple of years, which is very simple: Stating that for a quarter century the RIPE community's strength come from its breadth and experience, diversity of views and an open respectful exchange of ideas, value that we want all of our RIPE meeting attendees to uphold. Please treat each other with tolerance and respect. Free speech and open exchange of ideas are encouraged and celebrated. Demeaning, intimidating or harming anyone at the meeting is wrong, they are especially sensitive behaviour that offends based on gender, sexual orientation, religion, race or ethnic origin or other perceived social, cultural or personal differences. So with these thoughts in mind, let us start the meeting and engagement.
If you feel that you are in some way experienced that you are not in a trusted environment, we have two contacts that you can talk to, Mirjam and Nick, they are over by the door there, talk to them. For the next meeting, we have recruited a new trusted contact from the community, Rob Evans and he will get training and be a trusted contact at the next meeting. I am not sure if Rob is here. If not ‑‑ he is sitting over there. For the next meeting we will have his picture up here and he will be one of the trusted contacts.
So, what have we done since the last meeting? There was a discussion on a presentation at the last meeting which was very interesting analysing some figures on diversity, and if you look around the room, one of the questions is why isn't there 50% women in here? There must be something wrong right, we have a Working Group or task force looking at what can we do in order to increase diversity and there is a session on Friday this week in this room, in the morning, where we will have a panel and some discussion on that topic. And I think this is not only important to this environment but to the industry as a whole, why does not our industry attract at least equal parts of the population? We also have another task force working on accountability. There has been a lot of scrutiny from outside parties during the IANA transition that some of you may have heard of with accountability of ICANN. We have done a on documenting the account the of RIPE NCC and now we put together a small task force working on documenting the accountability of the RIPE community and as you may or may not know, the RIPE community is old, it's based on cooperation and a principle of as little procedure as possible, so we don't have long and heavy procedure documents; we have just enough procedures. But this may be ‑‑ may be a bit too little and this is perhaps some of the things that we need to review right now. We already started a small discussion group task force on getting in place formal process to replace me as a Chair, not because I want to run away but it would be good to have a process in place, and in case that happens I may not last 25 years in this position, and we have not made any progress on that, and I think that ‑‑ know that accountability task force is up and running, it's comes clear this is one of the things that comes in place so this is an activity that we need to discuss, it's not on the programme this time but we need to get the discussion on the mailing list going and move forward on that as well.
So, we have a meeting plan, you can find this on the website and click on it to see the programme, you have it here in your badge. And as you can see, today and tomorrow is plenary sessions, in the afternoon or evenings there are BoFs, birds of a feather sessions, and then on Wednesday, Thursday there are Working Groups. So if you are interested in Address Policy Working Group, make sure that you are present in the Working Group on Wednesday morning. If you are interested in the operations of the RIPE NCC, the Services Working Group, which is kind of the open half of the General Assembly for RIPE NCC where the activity plan and the services from the RIPE NCC is discussed, that is open to anyone. For the General Assembly with the formal votings and board elections, that is a closed meeting just for members as the dark blue there. I already mentioned the diversity plenary on the Friday morning and we have a closing plenary just before lunch on Friday.
None of this would happen if we didn't have volunteers to run this. So here is a picture of all the Working Group chairs. I think most of them are familiar to you, the last time we selected three new Chairs for the Database Working Group, Denis, David and William, so welcome to you. And I think there are in some other Working Groups, such as address policy, there is now a process to either re‑elect or replace one of the Chairs there. There may be similar process in the other Working Groups going on.
So if you are interested in volunteering, talk to the Chairs and volunteer in the Working Groups. There are microphones here, so what are you supposed to do if you are engaged and want to share some of your thoughts and ask a question? You go to the microphone and state your name and affiliation. And usually the newcomers are really good at that and the longer you have been at RIPE meeting the more you think everybody knows you but that is not true. State your name and affiliation.
The plenary programme wouldn't have happened without the Programme Committee, chaired by Benno, he will be share some words on this later on. He has Leslie as Vice‑Chair and I think also Brian as Vice‑Chair and Brian is also liaison between the Working Group Chairs and the Programme Committee. We have three representatives from the regional NOGs: Jan ‑‑ and then Janos is the local host representative in the Programme Committee this time and he will speak right after me.
There is a networking tool for the RIPE meeting. You can going to this URL and register so that you can make your agenda for this week available for all the other participants so that you can book meetings and meet other people based on your registration there. Unless you just want to meet in the corridors and grab people based on what you can see on their badge where you will see that all the Working Group Chairs have yellow badges, the PC has a PC I in the bottom and people with their stickers with their areas of interest on their badges, that is the low tech solution to network.
Socials: Some claim that some of the most important thing happens outside the sessions in the coffee breaks or in the evenings, tonight if you want to meet the RIPE NCC board you can be 18:30 in the foyer on the first floor, they also offer free drinks, if you just want free drinks and don't want to meet the RIPE NCC board, you can wait until 7 o'clock. The board may still be around but, yeah ‑‑ then, on Tuesday, there is a networking event and you find the map and locations in your folder, and if you have bought a ticket for the RIPE dinner that happens on Thursday. So what about Wednesday? Well, that is the do it yourself social so you have to get to know somebody and agree to go out for a dinner on your own, but I am quite sure that you are capable of arranging at least one evening for yourself.
RIPE NCC is actually 25 years this year, so there is some celebration going on. There is 25 year quiz, so you can pick that up from the registration desk or meet and greet, I am not sure I can answer all these questions but I am sure that you are able to find that. You can ask old‑timers or staff for clues and the winner will be announced on Thursday and there will be special post on RIPE Labs and a celebration on Thursday.
And then this meeting wouldn't happen without the volunteers, as I mentioned, without the sponsors that are listed here, the Council of Hungarian Internet Providers, the Hungarian Internet Exchange who are the local host, the sponsors. But last but not least none of this would happen without the staff from the RIPE NCC, who is making sure that technology works and that everything is arranged here.
So now, I will pass the microphone to the local host, Janos.
(Applause)
JANOS ZSAKO: Hello everybody. I would like to warmly welcome new Budapest. It's a big honour for us to host this 74th RIPE meeting, after 17 years we ‑‑ you come back to our town, which is a big pleasure but it is also an important date because it's the 25th anniversary of the RIPE NCC. So I am sure that you have a lot of possibilities to network during the RIPE meeting and to meet a lot of interesting people, but also don't forget to taste some of the good Hungarian specialities, I am sure you will have time during either the socials or when you go out on your own. I hope you will enjoy Budapest, but before I leave the stage I would like to present a bit who we are and what we do.
So, the Council of Internet Providers in Hungary, which is called ISZT, that is the abbreviation, it's CHIP in English, is an association which was founded 20 years ago, so that is also an important date for us, that is another important thing, and it is a nonprofit organisation, currently it has 37 members and we do three different things related to the Internet. One of them is the Internet Exchange in Budapest, BIX, which we run. We also have a cert, actually we are funding a cert and we also have run the.hu TLD. BIX is a neutral Internet Exchange with three locations in Budapest, where there is very good telecom connectivity in dataplex, datanum and the major node which is the academic networks as well.
There are around 60 members out of which about a third are international, so from outside Hungary. There is possibility to interconnect on IPv4 and 6; unfortunately, the IPv6 traffic is not that huge but we hope it will be growing eventually. We use Bird servers ‑‑ Bird route servers and we use Cisco technology for the switches. We have Nexus 7710. There are possibility toss connect on 1 gig, 10 gig and 40 gig and 100 gig as well as. We recently introduced re‑seller programme, which is very interesting and there are a lot of ‑‑ several telecom providers who have signed up. And BIX is member of Euro‑IX. The cert which is a computer security instant response team in another name for it, is sponsored by the council of Hungarian Internet Providers, so by us, and it is operated by the Computer Automated Institute of the Hungarian Academy of Sciences. And we also run the.hu TLD which is operated by a nonprofit daughter company of the association. The rules, the registration rules are set up by the association, but the operations is done by the company. We have over 700,000 domains, over 15% of these are signed with DNSSEC. We have a mixture of self‑operated name servers, four of them, these are located in Hungary and we have two Anycast name server providers who provide our service for us all over the world.
And the TLD uses registrar system so we don't have direct contact with the end users, we have roughly 150 registrars.
We would like to distribute some little token of appreciation that you have come here. We have some T‑shirts which will be distributed in the coffee break after the plenary, so between 15:30 and 16:00 and please don't forget to come and collect the T‑shirt. And I would also like to wish a happy anniversary to the RIPE NCC team who celebrated very recently the 25 years, and who are basically doing the job in setting up the meetings and I would like to thank them especially for doing such a good job.
Also ‑‑
(Applause)
I wish you a nice stay in Budapest, and in Hungary. If you have time to stay over the weekend then also enjoy Budapest and see you around the meeting whenever you want to contact me, you can find me. Thank you.
(Applause)
BENNO OVEREINDER: Hi. I am Chair of the RIPE PC, and yesterday I learned two things, so it's not Budapest, but Budapest and the other thing it's not the name Hungary, is historical mistake, the name, it's not the land of the hunts but the land of the Magyar people. I will ask Janos to pronounce it. That is the correct name of the city here.
So this is the RIPE PC, we were already introduced by Hans Petter. You see all the faces and names and some people ‑‑ we are all equal, of course, the PC is peers amongst peers but some people are more equal than others apparently, and that is me and my colleagues in the blue square. We are elected members, so we are elected by you, people here in the room. I will come back to that later. That will be ‑‑ and I have only three slides so please, stay tuned and pay attention here.
So I think Hans Petter already introduced us and the regional representation tiffs from MENOG, the Working Group representative and ENOG and Janos our host presented on the stage here. What do we do with the plenary or the PC, actually? The PC actually organises the plenary programme so we ask for submissions. We organise the tutorials and we kind of the organisation of BoFs is delegated by the the RIPE Chair, by Hans Petter to the PC to organise that. The plenary programme, we have 16 slots to fill and we were quite lucky, we received about 40 submissions, already very early in the whole process. So about 40% of the presentations are accepted for plenary presentations, and we had ‑‑ we were running also a new experiment, two experiments; one of them, what we call also the innovations, maybe that sounds a bit better. One are the two late submission slots, people can submit a late submission, one week ‑‑ up to one week before the RIPE meeting, so new developments or hot news can be presented at the plenary so that is I think is very useful and worthwhile. And the other innovation is that we didn't schedule Geoff on Friday but on Tuesday, please give feedback on that if you appreciate that. I understand you have a rough rip to Madrid anyway, maybe you can leave earlier. The other things are tutorials on Monday and the BoF and workshops. In the evening, and a separate note I want to make on the lightning talks: We have nine, nine plus sometimes. We filled three lightning slots for today. There are still six slots to hand out to you, please submit lightning talks, tell me the presentations, we have three slots for Tuesday and three slots for Friday. By the end of today we will make a selection for Tuesday, by the end of Thursday we make will make a selection for Friday. Please submit.
Rate the talks, very important, create your RIPE NCC access account, rate the talks, give us feedback. If we can improve the plenary programme, it's up to you.
RIPE PC elections, there are two seat for re‑election. You can nominate yourself. If you think it's great fun and it is, to help out with organising the plenary programme, nominate yourself, send an e‑mail to the PC at RIPE net mail account. Nominations, self nominations are open until Tuesday, half past three, and candidates can present themselves at opening at slots Tuesday ‑‑ Tuesday slot at 4:00. And on line voting is open between Tuesday until Thursday at half past five. So remember this. These are important message from me and I will close with that, and closing my own presentation, I want to open the plenary programme now by inviting Ed Lewis from ICANN to the stage. I hope he will mention the date but 11 October 2017 a major event will happen. And sorry, I will stay here. A major event will happen, but Ed and his colleagues will make sure it will remain completely unnoticed to us, so it will be a major event but he will make sure it will become completely unnoticed to us. Am I right?
EDWARD LEWIS: Yes. Hello, good afternoon. From ICANN, and we are going to talk about something you shouldn't know about. We are going roll the KSK and I will talk about that event, we have presented a few times already, so we will try to make sure we hit new points here, and make sure everyone is prepared for this. In this talk, first thing I am going to do is show you the new key, that is just for reference, it will come across if other ways, I will talk about the status of the project, where we are and we have a bunch of resources that we are preparing to help the community get ready for the events.
In one slide what we are talking about here is the top key in the process of validating DNSSEC data, I could go on for a couple of hours but I will keep it to one slide, we are changing the top key in DNSSEC. What is going on here is we have had in the history of mankind just one key so far, went from zero to one about seven years ago. That just meant those who cared about it come on, we are changing it for the first time, we have found that it in itself is a lot of work, one goal is that the change should happen smoothly with no disruption to the Internet and that is where all the work comes in and for further reference in the talk I talked about two keys now and then, KSK 2010 is referring to the old key, KSK‑2017 is referring to the incoming key, that is just about to come on.
Important milestones, these are the dates that Benno was referring to. We created the key at the end of last year and put the key into all of the places it needs to be to be production ready, it could be trusted by anybody that wants to trust it and it's actually in your hands. Currently, we are talking about the key, the key is not actually noticed on the Internet, it's apparent in a few places but you wouldn't see it until you looked for it right now. July 11th that is beginning to change, the key will finally appear in the DNS for the first time and it will start a process for the roll over, public process. So July 11th we see the first evidence that we are actually changing the key despite fact we have been working on it for quite a few months. October 11 is the biggest day of the event. If you are doing DNSSEC validation the key you are using today to trust everything will be changed to the new key and if you haven't followed that change you are going to have errors all over the place, so October 11th really is a day which there may be disruption if things don't go well. And finally 2018 we are going to clean up and go on.
The new key is going to be described in the next two slides, for those of you who don't follow DNS, DNSSEC rather, we have a key footprint, a ID number and the current one is 19036 which is not on the slide, that is the current key today; the new key is going to be known as 20326, that is a number derived from the key itself, and if you saw a DS record what you see up there is what would you see as the operational key. Before I talked ‑‑ gave a talk I checked on line to make sure these slides are accurate from what I submitted because this is a matter of trust, and they checked out. The other form of the record is the DNSKEY itself, this is the public keys rendering in the DNS protocol, this is the other format of it out there. These two are what we are going to be using, don't necessarily depend on this but they are there for to you look at.
The reason why I am showing a DS record and DNSKEY record, the tools that are used for DNS use different forms of this. These are just data structures to these things, we need to have one or two depending on whatever tools in place in your operations, so we are giving you both to look at for now.
So today, in the DNS things are going well, it's a sunny day scenario, we have no problems out there, we are changing it for maintenance purposes only, not because there is a reaction to attack or question of security out there. We are going to rely on automated updates of DNSSEC Trust Anchors and that is described in RFC 5011. This approach lets us go from the current key to the new key trusting only the old key. If you have trust and faith in that today because you are using that, using that alone you can get new key and it's based on timing. I am mentioning this, if we had trouble, go to boot strapping it's a much more manual process, inspect the key in their tools out there. You can do the latter if that is the way your operations would rather work. RFC 5011 all mated updates process, basically it takes the old key and signs the new one for a period of time. In that window of time which is 30 days according to the specification if you keep seeing the new key signed by the old key you can assume it's the trusted key. It's kind of based on assumption at this point because if there was a problem along the way we would say something different, you hear a disruption to the process saying don't trust the new key, so you learn it through osmosis in a way, by it being out there. And this software is out there that is able to just learn according to this process and I will get to that in a little bit. To get to the calendar, July 11th is when we put the new key in there for automated updates process. About one month later it should be seen as trusted across the land. If not ‑‑ you still have some time because it's not until October 11th that you have to follow the jump to keep validating the data so we have one month or so to trust the key if you just use automated process and two months to make sure that you are ready for the big jump in October.
What if in August you don't see a trusted key? You have two‑month to debug this. You can go back and find out why it didn't happen, what needs to be updated. You can also choose to bootstrap this from the start and you can bootstrap today, but around October 11th make sure if you are following the process it's worked and things should be fine. If not, we do have time to catch up. Most or many of tools that are in place today you have RFC 5011 support built into them so most of the tools out there, we have tested these and worked with the developers to make sure the tools work and improving the management of the tools work so you have more debugging insight into the tools. In sunny conditions this is the safest way for us to transit trust. It's also the most scaleable for folks out there. One thing I would like to, you don't have to do automated updates process. It's just what is easiest for to us reach the most people out there and it works. You can choose to do trust your own way, even use this one element of the way you might determine trust. So that is by the bottom part, trust is a local Poe see decision by the operators, it's up to you to decide what you trust, not what you are being told to trust. Keep that in mind in all of this work. If you decide to use automated updates, just follow the process out there, configure tools appropriately and they should work, if everything is put together correctly it should be fine. If you decide you want to do it manually or bootstrap from start, besides the on line presentation of the key we have the key in an XML file available at the URL up there, this has the essentially the information that was in the DS record I showed earlier, you can use that as input to the process, you might want to ‑‑ looking at this make sure you get a copy of this accurately, looking at the certificates for the web that you are using. You can use that that as one source of the key. There are also a bunch of other means out there, including when you download software you download tools for DNS, most distributions will include a configuration file which has the key in it and working with developers out there to make sure the next version of the software has the new key in it, in effect I think most of the software out there shipping includes the KSK‑2017 as an additional Trust Anchor in the configuration already. One tactic that one of the operators expressed to me a long time ago, his approach to trust is to examine multiple sources that don't share the same ‑‑ so you have multiple ways to get the key, compare them to each other, try a little bit here and there. You can't test this key until we start using the key for live in October, there is no way, we are not permitted to run extra data out there according to the policies and policies for the key management. So we have to make sure that we are ready to have everything put in the right place by then.
You can also trust keys from your friends if you trust your friend, that is up to you.
So, the call to action for those who are not operators out here, basically make sure your operator is aware of this and there is no disruption coming. We don't have an idea of who is doing DNSSEC validation out there, we have an asked ‑‑ we don't have a roster of all the people that need to know this, and that is a good thing. We are supposed to have a roster, we don't have it, this is coming, so if you hear about this and you are concerned about it go to your provider and say do you know about it, just make sure they are okay with this. If you are an operator I still have a talking to. What do you do? For some operators back basic reading of what you normally do. Be aware of what your system is doing. Make sure either ‑‑ you know if you are doing DNSSEC. Perhaps someone years ago set up name servers, turned it on but didn't tell anybody and they left. Make sure ‑‑ whether you think it is or not. Also, examine what you mean by trust, you don't want to be social engineered, get wrong key in your system, you don't want that to happen in any way. Test and verify, I am surprised a lot of times when I test and verify my set‑ups and it does what I think it does, it's important here, you don't want to be caught out in the cold in October. Look at configuration files, we spend a lot of time talking about having up to date software and versions of your name servers code, configuration files also need to be updated because sometimes they get left behind. I know it's been common in my practices. If validation is being done or it's being planned, make sure your plans and what you know about your system includes knowledge of this roll‑over event. You will have to know this to keep validation going smoothly throughout the process. For tools out there, these are the eight tools we have been working from that we are aware do validation out there and I want go through all of them. If you see one that we should know about and you think we should be considering let us know, but this is what we know of, right now.
BIND: BIND is a special case because of its history, BIND implemented DNSSEC way, way back in the early versions of it so it's possible someone has rolled out a DNS server based on BIND a long time ago with some of the old configuration files out had there and what is highlighted here is BIND, wants to use trusted keys which was a very static way to manage keys out there. It's been updated to use managed keys, in February 2010, and managed keys will let you do 5011, the automated updates if it's set up to do that correctly. But to ‑‑ don't use trusted keys any more to go to that and BIND is the only one at that time that existed back then with static management out there.
So Microsoft, that is documentation out there, they have lots of information. For other tools out there, unbound, not resolving, DNS mask, they have links in there to what they do regarding Trust Anchor management.
If you are running this thing and you start to see issues or problems occurring there are ‑‑ we have anticipated there are two kinds of problems will happen out there: One is fragmentation because there was a concern about the size of the messages. If you see problems getting the new keyset you might have a fragmentation issue to look into that and I will talk about that. Also, if you don't follow along, don't get the updated Trust Anchor, validation will fail across the board, everything, unsigned and signed zone, if you trust the root zone, you won't get referrals out of it it because it's telling you yes or no from that point. You have to look in the logs for your tools, each tool is different at this point but you are going to have to come up with a process to see whether it's succeeding or failing to catch up on any problems the day we make the roll.
So fragmentation, v6, and DNS, this has been one of the technical issues we were considering in the process. V6 fragments different from v4, basically it's different and that is an issue. V6 is done at the beginning and reassembled at the end but not in the middle. V6 will send back a message saying this packet was too big if it needed to fragment it. The problem for DNS is DNS has amnesia, it doesn't remember very well, so when it gets that message it forgot what it sent and can't retry that. So we are concerned about DNS will cope really well with DNS fragmentation out there. There have been concerns about 1,280 bytes as being the rough size limit of concern, and we will, in the process, cross 1,280 three times. This chart shows the sizing of the DNSKEY set during the process, which has been one of our design constraints out there and certainly the dates I have on the left side, those dates are the day in which this new size comes into play. On September 19th 2017 we will grow the size to a number of over 1,280 and that is one place people are concerned about that. There is also ‑‑ ultimately highest is January 11th we done certain revocation about by 10 more bytes. In fact, this was one of the constraints about whether we go to a new algorithm or stay with the one we have. So, we looked around and we actually have a set of serves out there which have extremely large DNSKEY sets for some reason or another and that is TLDs, some have a lot of large sets out there, many of them out there. We look at from different vantage points with the caveat nobody is really complaining about this but we have a lot of problem sets out there. So we took this and experimenting on this, and what we found was that if you run TCP things always work with one asterisk I will leave out for now but if you run TCP on v6 every TLDs keys arrive at the server so the lesson from this was basically make sure TCP works for your resolvers, it's a good thing to do. You can also in the second ‑‑ I have some test resources out there to make sure you can get large sets of data coming through, Verisign Labs has had a test out there for a while and they have updated for this process, DNS org has a test routine where you can see is there any reason why I can't get large data coming into me? These recommended fixes are not just for the KSK roll‑over, they should be there all the time. DNS has large responses, not just for KSK roll‑over. TCP is an important part of the process, make sure this is in place and this will ‑‑ make sure we don't have a problem anywhere across the board.
For recovery, three steps out there. . Number one, stop the tickets. If you have to turn off DNSSEC processing, do it. Make sure you don't get complaints while trying to fix this. We would like to you turn it back on, but if you have to turn it off it's not a sin, just make you get your work done. Number two is debug this. There are many ways things could have gone wrong. DNS is not the easiest protocol to debug. ServFail means so much out there, you need to figure out what went wrong. Did 5011 fail? Did the automated updates process fail? Are you having problems with thing from mentation, you can't do this without digging in your network. Test this to make sure it's running again, just to make sure. Don't run out there ‑‑ that looks really bad.
So, in kind of winding down on the talk now, we have been providing from ICANN a bunch of resource that is we would like to make available to folks, let people know about that might help in this process out there. The first one is, we have a Python script that is available from the GitHub which pull down the ‑‑ basically the Trust Anchors, suggested from us to you, pull down the Trust Anchors, we will write out files containing the DS and DNSKEY set versions of the anchors, and you can use this for boot strapping or whatever you want to do to compare this, you could also use the script as a guideline for how we see the trust being built, how do you calculate the trust. Mindful that calibrating trust, it's not the same as building trust. You can calculate it by the structures and so on, whether you feel it's the right data or not it's up to you. We have a test‑bed for 5011. In the ‑‑ we have talked about 5011 test beds in the past we were developers of software which one of the ingredients we sped time up to make this work. This is for operators, not for software developers. This one runs in realtime, so what that means it takes about six weeks to have the test complete. If you join the test today and you sign up for the test‑bed you will go through a process where it will take about a month‑and‑a‑half before you should see the entire process finished for your testing. We ‑‑ every week we run this. The current one is dated May 7th, it should be I think, I forget to change a four to a five. If you ‑‑ you will be guided through e‑mails and this is the signup page. You will get a bunch of e‑mails telling you how to configure your server, I think we have BIND and unbound instructions in there. You click here and you are on a mailing list and this tells you what to do and you have to configure hopefully a live production server with this information and what happens is you are not testing the root zone, you are testing a zone lower in the tree which should not affect your operations, it's in a real operations setting, it should be subject to all of your production environment, butts looking for tat which is not going to be interrupting any of your customers' access and it's in realtime, that is why it takes so long to go and I have done for this for two of the rounds in the past, it's worked for my set‑up at home, I have BIND and unbound and as someone who didn't build the test‑bed, I am independent user of this. See if this is going to be helpful to you and hopefully it will get you prepared for 5011.
We have one page for information, if you go to the ICANN.org website in the quick links there is a drop down or a listing for KSK roll‑over. We have a lot of information there. Just about everything is there, all presentations, it will be there and so on. And with that, I will open up for questions.
GEOFF HUSTON: APNIC. Thanks for the presentation, Ed. Part of this, though, is this is a tricky situation. It's certainly the first time that a DNS response that is larger than that magic v6 number of 1,280 objecting at the times is an integral part of making a validating resolver work and so it pays to be incredibly accurate about what we are saying publicly. I think I heard you say in the talk that v6 and TCP will always get the data.
EDWARD LEWIS: I say my experiment showed they worked.
GEOFF HUSTON: This is not true, unfortunately. Only I and K‑roots offer a low MSS in TCP. Everyone else offers big, 1440 so if you are path‑constrained, the root server needs to listen for and react to TCP ICMP messages. Yes?
EDWARD LEWIS: Yes.
GEOFF HUSTON: However only A and H. So 4 out of the 11 seem to do the right thing, four out of 13, sorry. The other 9.8, if you are sitting behind a constrained path, TCP will not work for you as it currently stands, unfortunately. I wish it were better but that is the results that I see. Thank you.
EDWARD LEWIS: Thanks for that. I will look into that more.
JIM REID: A DNS engineer from Scotland speaking only for myself. I have got two questions for you. The first thing is actually on the question of the roll‑over event itself, what do you think about the idea of telling people that are running validating resolvers to temporarily switch on soft fail mode for the validation failures so that in the event that something has gone wrong with the Trust Anchor they will continue to work albeit with unvalidated data?
EDWARD LEWIS: I think is that much different from turning DNSSEC off?
JIM REID: Not quite no. Still have it turned on but configuring the resolving servers to give answers if they get a validation answer so have a soft failure rather than hard failure ‑‑
EDWARD LEWIS: I have to say, basically, as an operator make sure if you are working on fixing this just stop the tickets. I guess I am not ‑‑ don't really get the difference between what you are suggesting and turning it off. But to save time right now, the number one thing, whatever you need to do not having more tickets come in, this is the operators' boat, DNSSEC is for the operators, not for us, not for ICANN and the providers. It's for the resolver operator to protect themselves. Number one thing, protect yourself.
JIM REID: I am suggesting here is not in the case of ‑‑ turn it off if something bad happens, have yourself in a situation if something bad happens it's not going to cause the sky to fall in and make you turn DNSSEC validation off.
EDWARD LEWIS: I will talk to you later to understand more of that question.
JIM REID: Your test‑bed for the KSK roll‑over, this gives me a bit of cause for concern because I have been bitten by this problem personally whenever bad things happened the name server tried to write a new trust anchor manged key file and it couldn't do it and then the sky fell in on my server. So I wonder from the experience you have got with that test‑bed for KSK rollovers, if you have been able to document instances of actual real problems that have arisen by that and how they manifest themselves, because if the DNSSEC validation fails, the way in which that then appears to the end user is not necessarily going somebody as obvious as just the ServFail that caused the problem. You end up with a situation where your machine is completely blocked. You need to know what those kind of failures look like, therefore if you see them in realtime at the roll‑over event you can say this is to do with the validation roll‑over rather than some other kind of random operating system problem.
EDWARD LEWIS: I think we should probably collect experience of those who have used the test‑bed, the idea ‑‑ it's been theoretically known as a problem, if we can start capturing actual experience with this, basically this is a real problem out there.
JIM REID: I would like to see the test beds using as that, not necessarily a semi‑production environment, but do it with an instance of the root zone albeit not on the route server infrastructure.
EDWARD LEWIS: Okay. Thanks.
JAN ZORZ: Any or questions? We still have few minutes.
AUDIENCE SPEAKER: I would like to ask a question that might be a bit interesting or you would frame as stupid, the old key, the private part of the old key will be ever published ‑‑ my name is Tamas Siklosi from Hungary ‑‑ the private signing key, will ever be published of of the old key, for historic reasons?
EDWARD LEWIS: The current private key is HSM and no one has access to it.
AUDIENCE SPEAKER: It will not be published?
EDWARD LEWIS: It will never be published, no.
JAN ZORZ: Thank you. Any other questions? Thank you, Edward.
(Applause)
JAN ZORZ: I am the Opening Plenary housekeeper, apparently. So our next speaker is Laura and we all heard about Tor and anonymity on Tor and Laura came from Princeton University and shell tell us the effect of DNS on Tor's anonymity.
LAURA ROBERTS: Thank you. Good afternoon, I am Laura Roberts and it gives me great pleasure to talk to you today about the effect of DNS on Tor's anonymity. This is joint work with Benjamin, Tobias, Philip winter and Nick. So let me begin by telling you why we started working on this topic in the first place. So Tor is an anominity network that lets people browse the web anonymously, allows users to circumvent government censorship. However, some Tor users end up with pages like this when they browse websites that are blocked in some places. For example, this happened when a user tried to access adult content with an exit relay located in Indonesia. The situation looks similar with exit relays located in India, so here the so‑called competent authority didn't like the adult content domain name that the user was trying to access so the authority blocked the site.
So this demonstrates that Tor isn't magically transporting users' traffic into uncensored territory. Instead, users are still subject to interference at exit relays and in this case DNS is being used to conduct this interference.
So let me now give you a quick overview of how DNS is handled in Tor.
So, here we have a Tor client on the left and the Tor network in the middle, a DNS resolver on top, and the example.com web server on the right. And the client is going to attempt to resolve the example.com domain name. Now, recall that DNS traffic is unencrypt sod we cannot have the Tor client ask its DNS resolver about websites it wants to visit over Tor because this would allow the client's ISP, the resolver itself and other adversaries to learn what websites the client wants to connect to which defeats the whole purpose of using Tor.
So instead, DNS queries are sent through Tor just like web traffic and exit relays are the ones who perform DNS resolution for Tor clients. Before our work, we knew very little about what happens once a DNS query is sent through Tor and what we knew was based on anecdotal evidence. For example, we didn't know what DNS resolvers exit relays were set up to use; we suspected that some performed their own DNS resolution in that some used a third party resolver such as Google's public DNS resolver, but we didn't know what else was being done. We also didn't know what autonomous systems the DNS queries were traversing, and we didn't know how these mysterious resolvers worked themselves. And as my example at the of the talk showed, the resolved domains weren't always what we expected.
So in your work we wanted to shed some light on the resolution process, and in particular we wanted to learn how DNS could be used to compromise Tor users anonymity.
So the first question we wanted to answer is, how exposed are DNS queries? So normally, in past traffic correlation studies, researches have only worried about the TCP traffic coming /OUPT of Tor and not the DNS traffic coming out of Tor and this is because past work has shown that an attacker who can observe traffic going into Tor and the TCP traffic coming out of Tor can potentially link the two and figure out what website a Tor user is visiting. So then we wondered if there are parts of the Internet that get to observe DNS traffic coming out of Tor and not the TCP traffic coming out, and what the possibilities were for leveraging that traffic.
So here is a visualisation of what I mean and we will go through this figure together. So, we had a computer, an AS 88 which is Princeton University, and from that computer we fetched the website BA ID U.com, before that we needed to resolve the domain name. So we had our computer run its own DNS resolver, which means that it did domain name resolution, starting from the DNS root server and from then on making its way down the DNS delegation path. So here we are showing all the ASs that were traversed as part of this process. So notice that we traversed four ASs for the web traffic, but 13 for the DNS traffic and eleven of the ASs were traversed only by DNS traffic. So to get a better idea of the situation, we have repeated the same experiment for the axe ex is a top 1,000 sites and we found that for all of all of the Alexa top 1,000, DNS only ASs accounted for 57% or more of all traversed ASs.
So getting back to Tor, this means that an exit relay that is set up to do its own resolution exposes revealing DNS traffic to ASs that don't have the opportunity to observe its corresponding TCP traffic. And we concluded from this experiment that DNS traffic is exposed to parts of the Internet that subsequent web traffic is not, and this means that there was a class of adversary that was ‑‑ that had been ignored thus far.
So we now know that we should probably pay more attention to DNS resolution in Tor. Therefore, the next big question for us was to understand how exit relays are set up to perform DNS resolution. That is, wondered how many of them were set up to use Google's public resolver versus how many do their own resolution, etc., because this has quite some impact on anonymity. So we designed an experiment to answer this question and we took the following steps:
So step one, we set up our own DNS server for a website domain that we own. Step two, using our exit map tool ways tool we maintain that can run a networking task over all exit relays, we made each Tor exit relay resolve a sub domain name that was under our control. We gave each exit relay its own unique sub domain name to resolve so we could tell them apart: Step three, we inspected our DNS serve logs, if it does its own resolution then we expected to see its IP address in our log. If it uses a third party resolver then we expected to see an unrelated IP address in our log, and we ran this experiment from September 2015 to May 2016, at least once a day.
So, here are the results of our experiment. In this table we are showing the minimum, maximum and medium percentages of DNS requests that the top four most popular resolvers could observe during the eight months of our experiment. So in second place we have exit relays that do their own resolution, which is what we mean by the word "local". And they represent around 12% of queries coming out of Tor on average. And in first place, we have Google's public 8.8.8 resolver that sees around one‑third of DNS queries coming out of Tor on average. And at times this number grew to over 40%. And we found this finding to be significant because it's alarming that one organisation is getting to learn so much about Tor users' behaviour.
So, the next question is, how can an attacker leverage DNS queries to identify which websites Tor users are visiting. We consider a threat model that somewhere in between end‑to‑end correlation attacks and website fingerprinting attacks. So remember in a traffic could relation attack the attacker can see ingress Tor traffic and egress Tor TCP traffic and he attempts to link the two. Website fingerprinting an attacker can only see ingress Tor traffic which is encrypted and he then uses machine learning on it in order to identify the websites that the traffic belongs to. In our threat model we assumed an attacker can see that ingress Tor traffic and some egress Tor traffic. On the ingress side, the attacker can be the user's ISP, some AS on the path or the guard relay itself. And on the egress side the attacker can be an AS on the path or a malicious DNS server. And then the idea is now for the attacker to do traditional website fingerprinting attack and then augment it with the observed unencrypted DNS traffic when ordered to improve the results.
To that end, we extended the Wa‑k nearest neighbours class fire from US EN IX security ‑‑ in order to come up with our two attacks. In the interests of time I will only talk about our high precision attack, so in our high precision attack we are going to accept the Wa‑k‑nn website classification, only if that website was also observed in the DNS traffic. So the addition of DNS data makes our attacks more precise and it turns out that our attacks worked very well for unpopular websites, and by that I mean websites that are lower on the Alexa scale which is problematic for dissident websites such as Wikileaks, etc.
Finally, we wanted to get a better understanding of how our attack would work at Internet scale, and for this we followed a well‑established method. So we simulated clients from the five countries that have the most Tor users, and we placed them in the ASes of the countries' most popular ISPs. Then we simulated their on line behaviour similar to ARIN Johnson at ‑‑ we made them visit several websites throughout the day. We used a Tor path simulator for Tor path selection and then we ran trace routes for ingress Tor traffic and egress Tor DNS traffic using the RIPE Atlas measurement platform in order to get the ASes that were traversed and we labourelled Tor connection as compromised if it traverses the same AS side on the ingress and egress side. What is nice about RIPE Atlas is that we have many measurement probes in the same ASes as Tor relays and we took advantage of that. And I am definitely happy to talk more about how we used Atlas to conduct our experiments.
Finally, we ran these simulations for four different exit relay DNS configurations in Tor. That is, what if all Tor exit relays were set up to use their ISPs's resolvers, what if all Tor exit relays were set up to use Google's public resolver? Third, set up to do their own DNS resolution? And fourth, what if all Tor exit relays were set up
ALEXANDER AZIMOV: They currently are, aka the status quo.
Here are the results of our simulations. This diagram compares the safety of our four DNS configurations for the exit relays. For each configuration, we have our five ISPs in the countries with the most Tor users, and distributions leaning to the right are bad because we want them to be as close to zero as possible. So comparing our four DNS configurations, local DNS is the least safe one, and again, this is the one where all exit relays are set up to perform their own resolution. This makes sense intuitively as these queries spread around the Internet the most as we saw earlier in that diagram that I showed. All other configurations look somewhat similar with ISP DNS being the safest, which makes sense because here we are assuming that the exit relays ‑‑ exit relays ISPs' resolver is in the same AS as the exit relay. Now, these results don't even in we should send everything over Google or that all relays should use their ISPs' resolver. Things are actually more complicated than that. So to that end, let's discuss a few counter measures that we came up with. We actually recommend that exit relay operators avoid using Google's 8.8.8 public resolver that Google doesn't get to learn so much about Tor users. And instead, we say that they should either use the resolvers provided by their ISPs or do their own resolution, particularly if the operators' ISP already hosts many other exit relays. So for example, some ISPs like host a disproportionate amount of exit relays and here we have one entity that gets a lot to learn about what Tor users are doing. Furthermore, exit relays that are set up to do their own resolution can be further configured to minimise DNS information leakage by enabling query name minimisation. So a Q&A minimisation DNS servers that are higher up in the hierarchy only receive the information they need to know in order to reply to the request and not the fully qualified domain name. For example, if we want to resolve www.example.com, we can ask the root name serve where.com is located versus asking it where www.example.com is located. But these are initial recommendations and they depend on who you want to trust, among other issues, so this definitely needs further study and I am definitely open to your feedback. And then we have long‑term solutions which include adding confidentiality to DNS, for example TDNS transports the protocol over TNS and TCP and deploying defences against website attacks should be an important long‑term goal as well.
So, now you know how DNS can be used to compromise Tor and what to do about it. The contributions of our paper are we discovered that DNS exposes Tor users' behaviour to more adversaries than previously thought, we ‑‑ that we discovered to Google gets to learn a lot about Tor users' on line activity. Another contribution is we created proof of concept de‑anonimisation attacks that demonstrate how DNS can make website fingerprinting attacks more pre sites. Performed simulations at Internet scale in order understand our attacks could affect real people.
Ultimately we learned the nature of today's DNS presents additional opportunities for Tor deanon‑misation and our work compels researches to continue to make how it more secure. The moral of the story is when you build a system like Tor you have to look at the surrounding technologies that it uses because they won't necessarily adhere to your system's security and privacy goals.
So here is our project website where you can find our paper, data code and replication instructions. I definitely encourage to you check out our paper because it's chock full of information I didn't have time to touch on here and please feel free to contact me or any of my team mates here and I look forward to taking your questions and feedback now.
(Applause).
JAN ZORZ: Thank you. Wow. We have 12 minutes for questions, and because I was looking at that direction I didn't see who was first.
AUDIENCE SPEAKER: RIPE NCC thank you for the presentation. I have few questions I will make only one but I am sure others will make the other ones. Multiple times you said Google learns a lot about Tor users. I don't think I can agree with that assessment because most of the queries that Google will get will be basically from the Tor ‑‑ it doesn't have the end user anything connecting to the ‑‑ so Google can identify end users. It's a Tor exit requesting something yes if it has ‑‑ might give some indication of end user, in Tor that is not true, gets some idea but nothing about the users.
LAURA ROBERTS: What you said is exactly what I meant. So if that didn't come across I apologise. What you said is what I meant. Thank you.
AUDIENCE SPEAKER: Benno Overeinder. Thank you for very interesting presentation. And I actually agree with putting more trust and confidence in your DNS infrastructure. You mentioned TDNS, and now well, I am now actually preaching from my own, plugging our own work, within the IETF there is a Working Group deprive, DNS privacy extensions which actually really focuses on that extension or of the DNS protocol, so TCP, TLS encryption of your DNS queries through the ‑‑ do the resolvers and maybe follow‑up work from the resolver to the authoritative name server but that is still to be chartered. And another plug, we have this privacy.org website where this kind of work is coordinated and it's already being implemented in OpenSource resolvers like Knot Resolver, people working on it, unbound, people with ISC BIND, also looking how ‑‑ how they can implement. There is a lot of work going on there and this is, again, I should limit myself, this is very good example why this kind of ‑‑ this work, DNS work is important. But thank you, again.
LAURA ROBERTS: Thank you.
AUDIENCE SPEAKER: Warren Kumari Google, I happen to be a no fee consultant to IFC ‑‑ Benno was mentioning, so I have seen this presentation a number of times.
LAURA ROBERTS: I recognise you.
AUDIENCE SPEAKER: You are probably going to know what I am going to say. You showed the big diagram which shows the traffic going up and hitting the root and ‑‑ what you didn't mention there is a bunch of caching so it's only a small percentage of queries which do that. You didn't mention a bunch of resolvers are now going to be done QA minimisation which ‑‑
LAURA ROBERTS: They are doing it you are saying?
AUDIENCE SPEAKER: It's start to go happen in certain places.
LAURA ROBERTS: Good news.
AUDIENCE SPEAKER: Maybe I should mention that more. The deprive stuff as well which people are concerned about this and are work to go mitigate it. So I guess I will mention all that again.
LAURA ROBERTS: Thank you.
SHANE KERR: And most of the things I had on my list people have already mentioned. Just a quick easy question. You said that it was more easy to identify people going to unpopular sites but how unpopular is unpopular?
LAURA ROBERTS: Oh, yeah, low on the Alexa scale, if you e‑mail me I can give you the cut‑off. Very nice talk, thank you.
LAURA ROBERTS: Thank you.
AUDIENCE SPEAKER: This is a quick one. Lars Liman from Netnod. I have questions for clarification. In the beginning you described how the queries traversed autonomous systems. What was your technique for figuring that out?
LAURA ROBERTS: Sure. So, I mean, do you want me to go over this example again?
AUDIENCE SPEAKER: What technique ‑‑
LAURA ROBERTS: We used trace routes.
AUDIENCE SPEAKER: In my view, that if I was you only half the path. You have no idea how the packets come back to you.
LAURA ROBERTS: Right.
AUDIENCE SPEAKER: It could be it traverses a lot more autonomous systems than you see. For instance, adversaries.
LAURA ROBERTS: You are right.
AUDIENCE SPEAKER: It's harder to at the sign that thing but it's something you should keep in the back of your mind, there could be even more people involved here than you see on the trace routes.
LAURA ROBERTS: Thank you, we didn't do the reverse.
AUDIENCE SPEAKER: If you step forward to your table over the ‑‑ that table. You have mentioned in the right column median values but you spoke about averages. So ‑‑
LAURA ROBERTS: I meant, okay, yeah the median.
NIALL O'REILLY: No current affiliation that I am declaring today. I really enjoyed the presentation. One slide that I missed, and you might want to put it into future versions of the presentation, and that is whether you have thought about which parts of the problem space are the most interesting to work on next and depending on how you react to that I may have a suggestion.
LAURA ROBERTS: No, I would love to hear your suggestion.
NIALL O'REILLY: This follows, really, on from Liman's comment about the small, less popular sites. Somewhere there is a necessary linkage between lack of popularity and vulnerability. If you have a very unpopular niche site it's only going to be the population that is interested in that niche site who are involved in it, so they are necessarily having their heads further above the parapet than some bigger more popular site which gives more anonymity of the crowd. So I am wondering if you have some kind of perhaps basian model which might give you some idea of what is the maximum anonymity or concealedness you could hope for in a site of a given level of unpopularity?
LAURA ROBERTS: Okay.
NIALL O'REILLY: I don't know whether that is a feasible problem statement but it might be something to think about.
LAURA ROBERTS: Thank you I appreciate that, thank you.
MARTIN LEVY: From CloudFlare. Really two quick questions: One, why is Tor any different than aonimity by just using a regular browser, the same DNS environment exists where you can definitely look at DNS queries even if you can't see https traffic thereon afterwards, so I just wanted to ‑‑ the talk assumes Tor because that is what you are focused on, but there is actually a baseline here where I think that you should compare this against just Joe regular browsing, where the same problems exist, whether you are at home, office, or in a coffee shop somewhere. That is sort of ‑‑ I am trying to understand the statistical aspect of where the baseline is for what you are trying to do. I am not arguing with the logic, I am just trying to see how one measures that and maybe in the back of my mind I am asking this question, at what point did anybody say that Tor was anonymous? I don't know if that question helps or hinders? I will take it off‑line. I understand the problem with the question.
LAURA ROBERTS: Yes, I am not quite sure I understand it. Maybe some clarification. Or I can talk about it off‑line.
MARTIN LEVY: Off‑line. The analysis on DNS is great; but it's just as valid in a non‑Tor environment as a Tor environment. It just so happens to be a mathematical point source as opposed to a spread out exit node. And therefore, part of this is Tor related and part of it is generic, absolutely standard exposure of everybody sitting in this room that isn't using Tor, for example. I am ‑‑ we can take it off‑line but there is something about the numbers that I think need to be adjusted.
LAURA ROBERTS: Okay. I definitely want to talk then. All right. Thank you.
JAN ZORZ: Okay Laura, thank you very much.
(Applause)
So, this brings us to the end of the Opening Plenary. We will be back at 4:00. We have two interesting presentations and also very interesting lightning talks today and I would also like you to invite you, at 6:00 operational task force meeting in this room, sigh at 6:00. Be back in half an hour, Martina will go around with a bell and wish you go coffee. Thank you.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE.
