EBERHARD LISSE: Before we start, can I ask the host to come to the podium already so that we ...

50 Pages·2016·0.18 MB·English

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