 Okay, so I'm gonna be talking about NSEC 5 which is a proposed modification to the domain name security extensions We've been working on this project for a couple years now So actually today I'm presenting completely new results in the sense that we've spent a lot of time implementing and optimizing this scheme So the performance results that I'm showing you are completely different and new and this implementation and optimization is both on The DNS side and also on the crypto side. This is joint work with a whole bunch of people money at Weitzman Demetris Previously at BU now at Maryland Leo at BU Yan at CZ Nick and now at a company called NS1 and we also have collaborators at Verisign Labs Okay, so before we get into DNS sec. Let's talk about how DNS works So here I am on my laptop at home and I would like to send a query to I would like to get data from a comm so I Need to know its IP address So what I'm gonna do is I'm going to ask the the DNS for the IP address for the name a comm The way I do this is I'm gonna go send a query to my local recursive resolver The resolver will go out to the internet find the name server that is authoritative for the comm zone Send the a comm query to that name server get the IP address in response and then relay that over to me And now I know the IP address for the a comm website and I can go visit it and I'm happy Okay, so that's DNS in a second DNS sec focuses on the exchange between the resolver and the name server The goal of DNS sec is to provide integrity. So very simply speaking We want to prevent a man in the middle from modifying the responses we get from the authoritative name server. Okay So what is NSEC five so NSEC five deals with a very particular problem in DNS sec It's the denial of existence problems. So in this little picture. I'm showing you I'm going to Q dot BU dot EDU Which is a website that doesn't exist the name doesn't exist So what the DNS has to tell me is that this name doesn't exist So there are various proposals for authenticated denial of existence showing that a name doesn't exist and sec five is one of them All the other ones are standardized by the way. This is a modification So what NSEC five provides is integrity not only against man in the middle But also if the name server itself is compromised It also has a second property which is the prevention of zone enumeration I'm going to tell you what this means later in the talk So new results that I'm gonna present today. We've spent a lot of time optimizing NSEC five So NSEC five we now have it based on elliptic curves, which is a new result I'm gonna talk about we have fully specified NSEC five. We've submitted a draft to the ITF I'm also presenting results from implementation and performance results that Demetris just got yesterday So these are completely new so before I get into the performance results I have to tell you basically what NSEC five is and in order to do that I have to go through sort of the history of the denial of Existence mechanisms used in DNS sec. Okay, so this is the the background All right So how does a denial of existence initially done in DNS sec? So DNS sec has a public key that for the zone This is known to all resolvers using DNS sec mechanisms that we're not going to talk about today We have our name server. We have our zone. These are the names that are present in the zone These are NSEC records. These are the way you answer queries for names that are not in the zone Okay, so what these NSEC records do is they take all the names in the zone They sort them lexigraphically so you see them alphabetical order here Then you take every consecutive pair and sign them using the secret zone signing key So this record is signed it can be verified using the public zone signing key Okay, so the query comes in for q.com. We can see that this name doesn't exist in our zone So we need to answer the query what we're going to do is we're going to just look up the NSEC record that covers this query You can see that q.com falls between c.com and z.com So you know that this NSEC record proves to you that q.com is not present in the zone Okay, so that was denial of existence in the DNS sec the very first version of how it worked But if we look at what's happening here our resolver not only learned that q.com is not present in the zone It actually learned that sorry that's validating. Okay, so it also learned that C.com and z.com are present in the zone. Okay, so it's learned some additional information It's learned that these names are in the zone and actually it's pretty trivial to enumerate the entire zone to identify all the names in The zone so here he's asking a query for b.com which comes before c.com He's learned that a.com is in the zone and you can see how this leads to an n query way of enumerating all n names in The zone if there ends names in the zone, okay So this is not just a theoretical thing These are this sort of enumeration attack is built into network reconnaissance software you have for example a plug-in into nmap that will Do this for you This was enough of an issue to lead to the development of NSEC 3 which is designed to raise the bar for zone enumeration attacks Some of the reasons given for why zone enumeration is an issue for example the RFC's mentioned that Registries may have legal obligations to protect their zone contents from a more technical Standpoint you can think of not wanting to expose all the names in the zone to any arbitrary person that's querying your DNS So for instance think about Internet of Things devices in there You may not want to expose their addresses You might think of a DDoS mitigation where you want to hide the names and IPs of servers so that they can't be attacked But they still need to be in the DNS so zone enumeration kind of squirts all of these security mechanisms So this could be considered an issue. So it was enough of an issue to lead to the development of NSEC 3 Okay, so here's how NSEC 3 works. We still we have the names in our zone I'm now showing you how to pre-compute the NSEC 3 records. We have the names in the zone We hash them each each one of them. So this is just the shawan hash of each name. We get these three values Then we sort them lexicographically So here you see they are in alphabetical order and then we do the same thing that we did before We sign every pair using the zone signing key and now we have NSEC 3 records Okay, so these are just like NSEC records But instead of having the names in the clear we replace the names with their hash values Okay, so as before we give these NSEC 3 records to the name server And now every time he gets a query in he again will look up an NSEC 3 record and return it How does he do the look up? He takes the query. He hashes it He gets this value here and he looks for the NSEC 3 record that covers it So we can see that C blah blah blah falls between a blah blah blah and D blah blah blah This is the the covering NSEC 3 record and now the resolver can verify that this is the correct Proof that this name does not exist in the zone because the value falls between the two values here And he can validate the signature with the the public zone signing key. Okay, so that's NSEC 3 So now we need to talk about zone enumeration We can think about zone enumeration in this setting actually there still is a zone enumeration attack here This was first talked about by Bernstein. It's been implemented by lots of people Maybe not first anyway. It was talked about by Bernstein and various people have implemented this thing So I've got this NSEC 3 record here. It's got two hash values here So what my zone enumerating attacker is going to do is he's going to just collect values from NSEC 3 records And here he can just send n online queries just to get all n hash values in the zone So now you've got all the hash names in the zone now. This is just a hash So now we just do an offline dictionary attack similar to password cracking And we re-reverse the hash values in the zone. Okay, so this has been implemented again This is you can use this as part of nmap if you want to do NSEC 3 reconnaissance for a zone and this this research paper found that they could reverse 64 percent of the hashes in the comm with one GPU so Zone enumeration is still possible with NSEC 3. It's just more work Okay So actually this leaves you in a problem because if you want to use DNSSEC today And you don't want to have zone enumeration at all you have to you move to online signing Okay, so what online signing does is it changes what's happening here? Previously our name server had pre-computed records that it was just using to respond to queries What we're now going to do is we're going to give the zone signing key to the name server Which by the way means that if the name server is compromised the entire security of the zone is gone Okay, but in any case you give the key to the name server and now whenever a query comes in You're going to compute an NSEC 3 record on the fly. So I'm just going to hash the value Here's the hash and I'm just going to take plus one and minus one of this hash value and Generate an NSEC 3 record that contains those two values So you can see that this value here falls between these two values and now we know that this is a covering NSEC 3 record for the query that was generated on the fly and this is great We don't have zone enumeration because these hash values are independent of any names that are actually in the zone They just depend on the query. Okay, so this is how we do the prevention of zone enumeration now with DNS sec Okay, so just to go over these are the different schemes that we have We have legacy DNS which never had a zone enumeration problem in before it with legacy DNS If you'd like to learn the names in the zone You need to send an online query for every name you suspect in the zone is in the zone That was the state of the world with DNS, but of course there was no integrity So there was no authentication for the for the no no signatures on the messages So a man in the middle could tamper with the messages Then we have NSEC 3 which has this offline zone enumeration through the dictionary attack that we talked about So you can make n online queries and then do offline zone and dictionary attacks to recover the names in the zone But it does provide integrity against a man in the middle and then we have online signing which doesn't have this offline zone enumeration problem and doesn't have a problem with Outsider attacks right, but in this case you have to do an online cryptographic signature and give the zone signing key to the name server Okay, so I have two things to say about that We can see the downside of online signing is that the the secret key has to go to the name server So if the name server is compromised the integrity of the zone is lost And another thing is in a paper from a couple years ago. We proved that any scheme that both Prevents offline zone enumeration and provides integrity against outsiders must necessarily perform one online Public key crypto operation per negative response So in a sense online signing the fact that we are doing online crypto here We do need to do online crypto in order to have both of these properties and this is sort of why we see the state of the world like this Okay So what does NSEC 5 do and sec 5 prevents offline zone enumeration without having to give up integrity when the name server is compromised Okay, so that's the trick that we use in NSEC 5 and now I'm going to show you why this works and just I wanted to note that In order to do this we do have to perform a public key Operation not a signature, but a public key operation for every negative response. This is necessary. We showed it in this theorem Okay, so now let me show you how NSEC 5 works. Okay, so just revisiting why was zone enumeration possible with NSEC 3? The reason was our attacker just collects all the hashes in the zone Which he can do with n queries and then he cracks them and the reason he can crack them is because he can compute hashes offline by himself Okay, so he can hash by himself. That's the crux of the issue So what we're going to do in NSEC 5 is we're going to get rid of this hash function Which was what was used in NSEC 3 and we're going to use a new kind of quote-unquote hash function Which is a verifiable random function. So for cryptographers most of us are cryptographers. Maybe you've seen this before This is basically like a keyed version of a hash function But it's a public key version of the hash function So there's a secret key that's used to compute the hash and a public key that's used to validate that the hash is correct Okay, so this is what we're going to use in NSEC 5 Okay, so here's how it goes. We have our names in the zone and now we're going to hash them quote-unquote With the VRF with the verifiable random function. This hash uses a secret key, which is the secret key of the VRF Okay, so here's basically what my hash is I'm going to take the name I'm going to do something to it with the secret key and I'm going to get a value in a second I'll tell you what I'm going to do to it. I'm going to do this for each one of the names. This should look familiar This is exactly what we did with NSEC 3. So we do a VRF Computation on each name. We get all these values We sort them and then we sign them using We lexic graphically sort them and then we sign every pair using the zone signing key So we get these NSEC 5 records. Okay, so this is exactly the same as before except instead of using SHA1 here We use the VRF Okay, so what is this VRF? So the first version of NSEC 5 that we presented a couple of years ago this VRF was based on RSA So in this VRF the pi function here was basically a deterministic RSA signature So I was a full domain hash RSA signature and this hash function here was just SHA256 Okay, so we basically take an RSA signature apply SHA256 to it and that gives us our VRF output Okay, the new version The new version of NSEC 5 that we're gonna talk about now I'm actually not going to show you the crypto behind it But the crypto comes from this paper by Franklin and Zhang actually the construction appeared in there It wasn't supposed to be a VRF. It was being used for something else So we proved it's a VRF and actually this construction turns out to be much more performant than the RSA construction I'll show you the performance results in later slides So in that construction this pi is an elliptic curve Comes uses elliptic curves. I'm not gonna tell you more about it than that Okay, so that's our VRF So here's our NSEC 5 records that we pre-computed and now we give them to the name server Okay, notice that I have not given the name server the secret zone signing key However, we do have VRF key that we have to give So first of all the VRF comes with a public key that everybody learns using the usual DNS sec mechanisms And then there's also a secret key for the VRF and that's what we're going to be giving to our name server So the secret VRF key is given to this guy here in a second I'm gonna tell you why this is okay, but for now, let's just talk about what we're gonna do with this thing Okay, so how does NSEC 5 work when a query comes in The name server needs to figure out what NSEC 5 record that has to deliver to the to the querier So how is he gonna do that? Well, he has to basically quote-unquote hash the query So he has to compute the VRF value So the first thing he's gonna do is he's gonna take this pi function apply it to the name and get this value That's using the secret VRF key Then he's going to hash this output And then he's gonna get this value here this value is Now he's just gonna look up the NSEC 5 record that covers this value So you can see that 3 blah blah blah comes before 7 and then 8 comes after so this NSEC 5 record covers This value here and now he delivers it to the resolver. Okay, so at this point you should say wait a minute How can you verify this thing right because the resolver cannot compute this hash value on its own? How is he going to verify this so what we do in NSEC 5 is we provide an additional piece of information which is called The NSEC 5 proof the NSEC 5 proof is just the output of the pi function So we take the output of the pi function and we send it along with the NSEC 5 record Okay, so the name server computes this thing sends it along and again in our RSA version This is just an RSA signature We send this along and then to verify we have two steps The first thing we do is we check that the NSEC 5 covers the proof So we just hash this value and check that it falls between these two values Then the next thing we do is we check that the proof and the query actually match So again in the RSA version the proof is just an RSA signature on Q comm So this amounts to an RSA verification. So we take the query we take the proof We verify them and if they match we know that these match and of course we verify the signature on the NSEC 5 record And now we know that this name doesn't exist in the zone. Okay, so that's NSEC 5 We have to give a proof record. We have additional keys Which is specifically used for NSEC 5 and we have to do this online computation in order to respond to the query Okay, the online computation by the way is comparable to what you do in online signing today in order to avoid zone enumeration They also have to do an online computation Okay, so to compare these different schemes Why does NSEC 5 prevent zone enumeration very quickly? We cannot compute VRF hashes on our own So that means that the zone enumerator cannot actually do these offline dictionary attacks because he can't hash by himself We do need to perform an online crypto operation when responding to a query But this is necessary by the theory that we theorem that we proved And finally I need to tell you why this provides integrity and that's what I'm gonna do next So here's my proof of why NSEC 5 provides integrity even if the zone's even if the name server is compromised Okay, so here's our attacker. He's compromised the name server. He stole the key So now he has this key and he needs to convince us that something is not in the zone Even when it is that would be an attack, right? So he's I'm gonna ask for a comm and he's gonna tell me no this doesn't exist in the zone That's what he's trying to do. He's trying to give me the wrong answer as you can see a does exist in this zone All right, so here's what he's gonna do first thing he's gonna do is he's gonna compute a proof record Actually, this is totally easy for him to do because he has this the VRF key and he can compute the proof on his own Remember, this is just and basically in the RSA version. It's an RSA signature on the on the query So he can produce this proof on his own The important thing is that the VRF has this property that the proof at least the RSA VRF and this follows to the other VRF as well the proof value here is going to be unique given the query and the public key Okay, so there's only one value that could possibly appear here And so this value better be correct also because the verifier is going to use the VRF key to verify the proof So this proof value is actually the correct proof value, okay? So now our attacker needs to give us NSEC five records that convince us that a comm is not in the zone But he doesn't know the zone signing key the secret key because it's not given to the name server So he can't forge NSEC five records. So he has to replay them Okay, but now if we look at the NSEC five records He has available actually none of them are going to work in terms of replay this one doesn't work It doesn't cover the hash of the proof value which starts with nine This one doesn't cover it if actually it matches it This one doesn't cover it and matches it and so none of these records work There's nothing to replay and that's why you integrity is preserved even if the name server is compromised and this the VRF key is leaked Okay, so that's how we get the security events like five and if you think about it This is exactly why NSEC three is secure if you just get rid of the VRF and just think of sha one This is exactly why it works. Okay. It's the same idea Okay, so I just showed you why we have integrity even if the name server is compromised and so this is kind of this state of the world these are the options you can have Offline zone enumeration be robust to name server compromised, but not and not do online crypto Okay, so if you don't care about zone enumeration, this is a good solution if you care about zone enumeration in this solution You lose integrity of the name servers compromised and you have to do online crypto versus NSEC five where you do not lose integrity If the name server is compromised and you also have to do online crypto Okay, so that's basically the state of the world and now I want to show you some of our new performance results So we've actually gone and implemented NSEC five our implementation extends existing DNS Commercially available open-source software. So our name server implementation uses not DNS and our recursive uses unbound We have both versions of NSEC five implemented the RSA version from our first paper and then this new elliptic curve version I'm going to show you that this version is more performant in a second also Some really cool things that we incorporated in the new version is that we looked at some optimizations that the DNS community developed for NSEC three, but they were actually developed after NSEC three were standardized So they were never actually used so we actually are able to incorporate these optimizations into NSEC five and that gives us a much better performance I'm not gonna talk too much more about these I can talk about this offline So nine thousand lines of code we use open SSL which was already inside these Implementation so there's no new dependencies. We didn't really need any new crypto. We just use the crypto that was in these And also the optimizations that I'm talking about are all protocol level Ontanizations we did not do systems level optimizations here. This is just extensions of existing implementations Okay, so the first thing that I want to show you is the length of the responses. So Let me let me just read to you this chart and then I'll tell you why we care about this So this is the response length in bytes. This is the length of an internet packet And these are different versions. This is NSEC three using RSA NSEC three using ECDSA This is NSEC three online signing using ECDSA. So these things are roughly the same NSEC five using RSA and NSEC five elliptic curves, okay So first of all, why do we care about response links with with DNS sec? There's two reasons for this first of all in DNS when you send a query it goes over UDP And you want the response to fit in a single packet because if it doesn't either the packet get fragmented and bad stuff happens Or you have to redo the query over TCP which adds more latency So it's really nice if your response fits in a single packet and we can see that our RSA version of NSEC five actually did not the 1024 2048 version of NSEC five also doesn't fit into NSEC three doesn't really fit into a single IP packet either So these are bad things but When we move to elliptic curves, you can see that NSEC three does and NSEC five also does and in fact that the NSEC five based on elliptic curves in terms of length is roughly comparable to NSEC three based on elliptic curves Okay, so this comes from the fact that we've done the elliptic curves optimizations and also the DNS optimizations The other reason why we care about this is actually Because the DNS can be used as an amplifier for distributed denial of service attacks You can imagine an attacker spoofing the IP address of a victim Sending a query to the name server and the name server responds to the victim if that response is really really big then the victim You know the rate of packets going to the victim gets higher the rate of bits going to the victim gets higher and that's bad So we don't want to blow up the length of responses. That's another reason why response length matters Okay, so when we do NSEC five with elliptic curves, we're actually not losing much in terms of response length relative to NSEC three Okay, and this is based on our implementation Actually, the other thing I wanted to say is that today most of the DNS sec uses RSA 1024 Not 2048 so this is what the response links look like basically and many implementations now many deployments now We can see that moving to elliptic curve and sec five is actually shorter than what's currently being done in the deployments Okay, the last thing I want to show is the throughput of our name server So what we did here was we set up a name server And when I say we I mean Demetrius and Schumann So there were 24 threads running on 40 virtual CPU So this was a big box what you might imagine be acting as a DNS server What we do is we send queries to this box at a steady rate You can see we started at 8,000 queries per second up to 128,000 queries per second and we see when the box can no longer respond basically we're in max is out Okay, so this this line here is the NSEC three line Remember that NSEC three you actually don't have to do any online crypto You just have to do a hash and a look up so this scales basically perfectly, but this is a log log scale So this line is linear Okay, so NSEC three has no problem scaling, but when you start to turn on online signing This is an online signing implementation from power DNS This is by the way everything here that you're seeing other than this purple line is not DNS Reason we use power DNS is because power DNS was the only open source RFC compliant thing that we could find that was doing Online signing so we use that in the evaluation We can see that online signing with power DNS is maxing out around I think 21,000 queries per second Our RSA implementation of NSEC five maxes out similarly around like 19,000 queries per second If we look at our NSEC five elliptic curves into implementation, we're maxing out at 64 thousand queries per second, so we're pretty excited about this result I still can't really put this into context because this is from yesterday this figure and One thing that we did to do is we looked at the average query rate at the root And that is about an order of magnitude lower than this on average, so we think that these numbers are pretty good I'm happy to talk more about what these numbers mean again. They're really new So this is an ongoing Project we are continuing to do performance analysis, so we haven't tested the resolver performance yet We have to do that We're also going to use captured traces as opposed to this these synthetic queries that we're coming in at study Rate that I've shown you and we have an internet draft We're hoping to get this included into the DNS specs and the implementation is publicly Is publicly available so with that I'll stop these are some memes that we didn't make we just found on this website So thank you, so we do have time for questions, so let's go right ahead Thanks for the nice talk, so I have two questions one the obvious question is what happened to four What happened to two as well The real question is so you talked about replay and and how replaying doesn't work But what how do you prevent replays from a previous time when there really wasn't an a dot-com? Yes Okay, so that's kind of not my problem in a sense because that DNS tech has this problem anyway So the question is how do I prevent steel records from being replayed? So DNS honestly, I can't answer this question very well because there are all these mechanisms like TTL that are being used And figuring out exactly what the right TTL is and when you should expire your signatures to make sure that things are expired before you add The new data so anything that's dealt with in that way in DNS tech We just like drop into our scheme here, so you know, I don't really have a better answer than that So Trevor Perrin has a very fast and simpler VRF called VXN at DSA So Did you consider using any other VRF or would you consider that for I have I didn't know about that That's really interesting. So I'd love to look more in that. Maybe it's even the same VRF. I don't know So yeah, I'd be very interested to see which one you're using exactly But yeah, it's one that we proved was a VRF. So it may end up being the same thing. Could be okay. Thank you Hi, my name is Victor de Chauvin a Work on Dana bunch depends on DNS sec I'm not sure if this is exactly a question or a comment, but for many domains, the highest risk is operational More than than crypto people forget to redo their offline signing and their domain disappears off the internet So for folks without very strong operational discipline and you know support teams and so on Actually having the key present on the name server is important so that you can keep signing Right so that the NSIC became a lot more reliable once bind implemented Automaintain and people could leave their keys online and have the name server automatically Resigned I understand of course the roots and comm and so on have ways of doing offline signing reliably But for the sort of average much smaller domain The keys do have to be online because otherwise the the risk of going dark is much higher than any risk from compromise So that's sort of a trade-off That people have to be aware of in that offline signing is cool, but most people can't do it reliably I think that's that's all I have to say for the moment Okay, I guess I just I just wanted to say to that, you know, I I take that point. I think Just what we can I get my slide back up, please All right, I Just wanted to point out that in the case where you want all of these things This is this is the way that we're proposing that it will be done Right. So again, if you don't care about zone enumeration, then you shouldn't be doing this But if you do then this is this is the way to do. All right, so let's thank Sean again