EN HYDERABAD – Tech Day (Part 2) HYDERABAD – Tech Day (Part 2) Saturday, November 05, 2016 – 13:45 to 15:00 IST ICANN57 | Hyderabad, India EBERHARD LISSE: Before we start, can I ask the host to come to the podium already so that we have got the speakers? Welcome, everybody, to the postprandial session. Of course, I must always punish the latecomers, and since they’re not there, I’ll punish the ones that are here. The next presentation will be what I usually call the host presentation. It has been a tradition that we always invite the host for a presentation of their choice. Without further ado… UNIDENTIFIED MALE: Good afternoon to all of you. Thank you for this opportunity for this host presentation. I’d like to mention C-DAC, the organization which I came from. C-DAC stands for Centre for Development of Advanced Computing. It’s the premier research institution under the Ministry of Electronics and Information Technology of the Government of India. We are fairly spread across the country at 11 locations. We work on entire gamut of IT technologies. Note: The following is the output resulting from transcribing an audio file into a word/text document. Although the transcription is largely accurate, in some cases may be incomplete or inaccurate due to inaudible passages and grammatical corrections. It is posted as an aid to the original audio file, but should not be treated as an authoritative record. EN HYDERABAD – Tech Day (Part 2) We are coming specifically from C-DAC-Bangalore. It’s a small team. We work on [inaudible] cybersecurity research, cloud and HPC, language, computing, and ICT. I specifically [inaudible] and Internet Engineering Group. We work on parameter security solutions, information security solutions, and Internet standards. Here the Government of India, through us, has been trying to promote the development of Internet standards to increase the contribution of Internet standards in the country. We have recently started an effort called Indian Internet Research and Engineering Forum, iiref.in. People can visit that. We award fellowships and try to improve the participation of the Indian community within the standard development process. So that’s one of the activities that we do. Here of specific interest, we have been associated with ICANN since 2013. We have members from ICANN contributing and trying to bring out the knowledge on DNS security to various participants. These are the two important things which made us come here. With that brief background, we thought we can share some of our work which is being done. Page 2 of 50 EN HYDERABAD – Tech Day (Part 2) Our agenda is basically to draw the synergies between TLS and TLSA. In India, we have the hierarchical trust model, where, if you want a digital certificate, whether it’s an SSL certificate or a signature certificate or whatever – e-mail certificate – you need to approach a certifying authority. The certifying authority has to be licensed to be a root-certifying authority of the country, with is called a CCA. If that is the case, then your certificate is legally valid. If there is any issue or attack happening, you can approach the court and you have some sort of remedial measure. But if you don’t follow this part and you try to take a certificate from some other institution or organization which is not authorized with the root- certifying authority, then it’s up to you to do it. This is the scenario which is prevailing in India. But there are issues, as you know, that applications maintain their own trust store. For example, Mozilla has its own trust store. And applications like Adobe PDF have their own trust stores. The thing is that whatever the root-certifying authority of India’s, as well as their CA (certifying authority), should be loaded into the trust stores. When you consider users who are not experts or [inaudible] to these aspects, and if they visit a website which is having a certificate, which is actually licensed Page 3 of 50 EN HYDERABAD – Tech Day (Part 2) by the root-certifying authority of India but is not loaded into the trust stores, it becomes an issue. The user may see a message from the browser saying that this particular website is not to be trusted. So he backs off. So in such kind of scenarios, organizations move to other well- recognized certifying authorities, which can have a widespread acceptance. But legally, of course, they don’t have any sanctity. So this is a scenario which is prevailing here. Of course, I want to show the Board the positives and negatives of what is happening the process of TLS certificates and, of course, DNSSEC/DANE, which is TLSA. TLS. Just a brief introduction because most of you would be aware of it. The structure of TLS is a very complex one. There is a handshake protocol which establishes the connection. It shares the keys, etc. There is a [record] which actually carries [inaudible]. And there is quite a big length of cypher-suites which are there. Of course, TLS 1.3 is in the discussions in India. So it’s in the TLS community, and the IETF is making it up. The objective is to clean up the latest version of TLS [on BIND 2], increase the security, and improve the performances. Page 4 of 50 EN HYDERABAD – Tech Day (Part 2) But the main thing here is the certificates. Certificates are the key. Certificates which you obtain from certifying authority actually stands as the key for this. But, again, of course the validation process of a certificate is quite a complex thing, including browsers, as well as applications do that. Maybe if I want to distill the process as a [inaudible], this is here. Basically, you need check for the validity, the time, the CRL certificate [inaudible] certificate, etc. And you need to validate the signature which is present in the certificate. Please note there’s a recursive algorithm, but we have just put up the basic steps here. So they issue us a certificate. If it’s not self-signed certificate, then you need to continue. Again, you need to go back. So the entire chain of certificates need to be downloaded and it needs to be verified. This is what typically happens in a certificate validation. Of course, you have to treat the root-certifying authority, which is generally a self-signed certificate, as a special case. That is step #4. So that’s the entire process which we have briefed up. Of course, applications manage their own trust stores and come up with a set of pre-loaded certificates. In countries like India, Page 5 of 50 EN HYDERABAD – Tech Day (Part 2) we have a separate trust chain. Those certificates don’t come up with the applications that are pre-loaded. But the user may be using such applications. For example, if I send you a digitally signed PDF document which has been issued by a licensed Indian certifying authority, it may be saying that it is not able to trust it. So now it is up to you to figure out which certificate is missing, and you need to add the certificate and see if you can trust it. This is an issue which skips going between the application developers and the certifying authorities, but that is one side of the equation. But of course, if you trust the certificate and a citizen of this country, you can explicitly add certificates of this domain, which you want to trust. So this is what happens in the trust stores. Of course, this is a very brief overview. Now I’m jumping into the next topic of DNSSEC, which everyone, I think, in this room should be aware of. With DNSSEC, you have a secure connection the DNS server also. Of course, DNSSEC [inaudible]. Every zone has two crypto key- pairs. This makes it a little complex, but of course I’ll just run Page 6 of 50 EN HYDERABAD – Tech Day (Part 2) through the steps. Operational keys: you have the zone-signing key as well as the key-signing key and delegation signers. Of course, DNSSEC uses public key cryptography and digital signatures to provide data origin authentication and data integrity. It provides protection against spoofing of DNS data. That is, it tries to avoid corruption of the content. But it does not provide you the secrecy or confidentiality. It does not protect you against the DDoS attacks. This is actually another slide which explains the processes involved in DNSSEC. This animation is available and in [inaudible] format, but unfortunately I can’t show it here. It’s in [inaudible] you can have the complete animation which is being there. So that’s the thing. Coming back to the next step, that is DANE, which completely based on DNSSEC. It allows the pinning of the TLS certificates into the DNSSEC zone, TLSA. But there is one issue with a TLSA record. TLSA is basically one of the record types that is available. It is introduced and allows the pinning of the certificates. It allows a self-signed certificate or any arbitrary self-signed certificate, and there is an opinion floating in the community that it also provides the required security and one need not approach a hierarchical trust model. Page 7 of 50 EN HYDERABAD – Tech Day (Part 2) But then there is a risk in it. That risk has been recently identified in a draft, which we discovered it on October 9th, 2016, which actually talks about an unknown key-share attack, where an attacker is having a secure connection to a server but none of them know that they are actually going through a man-in-the- middle. So that is a simulation which is being described in this RFC draft. Of course, the main issues is that, in the TLSA, a validation step [must] be there, validating the server certificate, which it has received from the DNS. But now we produce a self-signed certificate. There are four cases which are there. The last case is basically the risky one. That is, if you are using a self-signed certificate – that is, especially when the code is 03. There is one self-signed certificate which is shown there in the listing we have set up. So basically, the risk is, if you are using a self-signed certificate which has not been authorized by any CA, then you run the risk of attacks. Right now, I think the attacks are in a discovery phase. One of attacks has been documented. Of course, some mitigation strategies also have been mentioned in this particular draft. So these are the thing which have been coming up. We would like to conclude basically by saying that both TLS and TLSA are Page 8 of 50 EN HYDERABAD – Tech Day (Part 2) required to establish the current level of communications. Most likely, if you have a hierarchical trust model, it will help you to have that safety feature. Of course, there are complexities. There are issues in the validation of certificates, and there are attacks which happen, but that can be resolved. But this is one simple thing which can be done. So though TLSA can stand independently, we suggest that it should avoid the use of self-signed certificates, but rely on certificates which are issued by a valid certifying authority. So that’s the part of it. Thank you. There are some references that are given here which can be looked into. Thank you. EBERHARD LISSE: Thank you very much. Any questions? All right. Give him a hand, please. Rick is the next presenter, so he can ask his question now or later. RICK LAMB: Oh, okay. Excellent presentation. I’m just trying to make sure that I understood the driving force behind it. It sounds like you’re saying that, for some of the trust models that you have here in India, these are not automatically included in Internet Page 9 of 50 EN HYDERABAD – Tech Day (Part 2) Explorer, in Microsoft, and – is that true? So it’s not there by default? UNIDENTIFIED MALE: Yes. It’s not there by default. RICK LAMB: Okay. That makes this very interesting to me. This is an opportunity. I’m obviously a DNSSEC geek. I’m very excited about this. This makes it an excellent example where DANE and DNSSEC can actually maybe help expand this trust model. So that’s what I was just trying to understand. To me, that was subtle, but that was really cool. Thank you for that. EBERHARD LISSE: Okay. If there’s no other questions, thank you very much. Now we move straight to Rick Lamb, and then the other two presenters can start moving towards the podium. RICK LAMB: Okay. All right. That was a perfect segue into what I’m going to talk about. I’m going to try to do a demo. Demos never go well, so I have some backup slides. If you pull down these slides, you will see screenshots of how it should work. Page 10 of 50