Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/448 Thanks!
Thanks. Good afternoon.
I hope everyone's had a great Congress.
We're getting quite close to the end and
it's been a lot of fun for me and it's
great to be here.
I'm s I'm from the Electronic Frontier
Foundation, and I'm here to talk
about a project that we've been working
on actually for about three years
in some secrecy.
And it's really excellent to have this
public and to be able to talk about it
and to be able to share our ideas
and our plans with everyone.
So there are a lot of acronyms in this
space and this is really only a tiny
selection.
And I just wanted to start by letting
people know if there are people who don't
work with certificates or with
Web encryption a lot the really
most fundamental acronyms that occur the
most.
So the protocol that we used
to use as a security layer on top of TCP
was called the SSL when it was invented.
The proper name today is TLS.
That refers to the same protocol and it's
more recent versions.
And of course, when you put that
on top of your underneath your
Web connection, you've got HTP.
We've also got the format of the
certificates for
exchanging the public keys that we use
in these connections.
That's called X five or nine.
The infrastructure that that forms
the basis of is called the public key
infrastructure or pecky
and the entities that.
Publish that sign, the certificates
within the PKK are called certificate
authorities or case
there are many more acronyms out there,
but I'll try not to use too many of them.
So this is a technology for us as privacy
advocates that is really fundamental.
That's really important to them that
we've been advocating for a long time
and we started from a place where people
had this sort of Web
security folklore, that
you need a secure connection to your
website if the user is entering financial
data like a credit card number.
And that's really weird
because credit card numbers are not
really that sensitive.
There are a lot of other things that are
obviously much more sensitive
than a credit card number.
But the folklore persisted for many, many
years that that's what this technology is
about. That's where this technology is
needed, that you use it
when you're accepting credit card numbers
and otherwise not.
And in the last few years, the Web
community has said, OK, also, if the user
is logging in, we need to protect the
username and password.
And OK, after the user has logged in, we
need to protect the authentication
cookie.
So gradually there has been an expansion
of the recognition that this technology
is important.
But I think we need to go much further
than that.
And I don't really think that I have to
convince this audience of that.
But I think we need to convince other
audiences of this that we need a much
stronger vision, that the things
around us, our communications networks,
are actually attacking us all the time
on a large scale routinely,
that these networks are untrustworthy
and that we need to protect our
communications against them for many
reasons, for many threat models against
many attackers in many different
situations.
And there isn't just one reason for that.
There's a whole panoply of reasons
why we ought to think of networks as
untrustworthy and why we ought to think
of network protocols as needing to
protect communications against the
networks.
And plain HTP was never intended
to protect communications against the
network in any way.
It's totally unsecured.
The information is totally in the clear.
The network operator, everyone along the
path has the full ability to spy
on everything that you do and to modify
it and to inject things.
So just to be concrete and this is just a
quick representative sample, not the
full set of reasons why we want secure
connections.
We've got issues like skyjacking and
location tracking.
So if you have a cookie, it might be
an authentication cookie.
It might just be a tracking cookie.
If someone else can see that cookie,
that cookie can be repurposed to steal
your session, to impersonate you or
just to recognize that that's you.
And we heard last year that governments
noticed that and that there is a lot of
infrastructure that's been created to
say, OK, that cookie wasn't meant
to be personally identifiable, but it is
to us because we know who that person
was. And therefore, whenever we see that
cookie sent to that site,
we know who that is.
We know where that person is.
We can recognize that device immediately.
There are also software downloads.
I was just hearing about a really popular
tool for creating
installation media for Linux systems.
And you use this tool and you create
bootable USB media.
And I looked at how does it get the
images for your installation media?
And the answer is there's a hard coded
list of 261
URLs from which ISO
images can be downloaded.
According to what operating system do
you want to install?
What version do you want to install?
None of those 261 URLs
is a secure origin.
All of them are HTP
or FTP with no checks on
verification and no signature
verification.
So you're making installation media for
your operating system and your tools
are going out there and getting your
operating system over a completely
unauthenticated, completely insecure
connection.
And you're installing not necessarily
what you wanted, but whatever your
network operator wanted you to install.
And that pattern is repeated over and
over again with all kinds of software.
People are downloading unauthenticated
software and installing it and entrusting
their computers and trusting all their
communications to software every
day.
Reader privacy is another really
significant one.
So sometimes we hear from
people who publish websites like
newspapers, they say
all of the content on our website is
public.
There is nothing secret on our Web site.
We don't need it.
Setpiece.
The confidentiality of the sensitivity
there, as with so many other sites,
is not in the secrecy of the content,
it's the sensitivity of the association
of the reader with what the reader
is choosing to read.
Librarians understand this very well.
Every book in the library, of course,
is completely public.
Anyone can walk in and read the contents
of the book in the library.
There is no attempt to say that this
library books are secret, but
the librarians understand it as a
fundamental ethical responsibility
to protect the association
of the book with the reader, to protect
the fact of who is reading
what.
Librarians have articulated this a long
time ago, and website operators
and publishers need to articulate this to
everything on your website.
May maybe public your readers have a
really important privacy interest in
the selection of what they read on your
site.
Another significant point is
content based censorship built into
networks, a lot of people are familiar
with this through the Golden Shield
Project in China, where if
you access a website that mentions
certain keywords, the Golden Shield
will actually interrupt your connection
to prevent you from reading about that
topic. Unfortunately, more and more
countries are building that kind of
censorship infrastructure directly into
their networks.
And so we need as an anti censorship
measure to prevent
the network operators from being able to
see what we're doing and what we're
communicating about and with whom we're
communicating online.
And just recently, we've been hearing
more and more about mobile
carriers injecting headers
and broadband carriers, injecting
advertisements into people's Web
connections.
So your ISP will advertise to you
by actually tampering with your Web
connection and putting an ad banner in.
Or your mobile
carrier will say, I want to help sites
track you. So I'm going to put in a
header that shows who you
are.
So all of these forms of tampering and
these skell all the way up from these
commercial motives, of course, to
government surveillance motive's
where we heard last year at the Congress
about governments creating massive
infrastructure to actively inject content
into people's Web connections as a way of
delivering malware, as a way of
compromising people's devices.
So it's a widespread tactic that a lot of
people are interested in for a lot of
reasons.
So we need a vision of a secure
web that can defend users against these
things of really routine use of
encryption.
There are a lot of barriers to this.
We've talked to a lot of website
operators about why don't you use
HD on your site?
Why don't you have a secure connection to
your site?
And we hear a lot of things.
And one is the traditional view that it's
slow, that it makes it adds
latency to the process of
establishing a session when the user
first connects to the site or that it
puts a lot of demands on the CPU
of the server.
For some people who have a complicated
server side configuration with load
balancers, there are additional
complexities about engineering
considerations with key management.
But the one that we hear over and over
again most often.
Is all about the difficulty and
the cost of obtaining and
keeping up to date and keeping accurate
and keeping non expired, these
certificates that you need in order to
let the browser establish a secure
connection to your site.
And we've talked to people who are
technically sophisticated, people who
understand what a crypto key
is and they understand what a Web
server is and they understand what
a digital certificate is and they
understand why they need it.
People who understand all of that
still typically take an hour
to actually go through the process and
actually get and deploy the cert if
it's not something that they do on a
regular basis.
Obviously, if it's something that you do
every day or every week, you become
more accustomed to it and more familiar
with it and you can get faster at it.
But we've heard over and over again from
system administrators who only have to
deal with this, say, once a year
that they have to go and look up a recipe
on some website about how do you get a
cert. And they have to go through all of
these steps, creating a key, creating
a certificate status request.
They have to deal with the syntax of open
SSL command line binary
dash.
No doubt some
of you will appreciate that.
Yeah, no doubt.
All right.
So this is this is a complex process
that's really a deterrent to people.
And, of course, there's a financial cost
associated with it, too.
And that's typically a financial cost per
subject, domain names.
And even then, of course, a
year later, it's going to expire and all
of your users are suddenly going to get a
certain error or you're going to add
some virtual hosts, some subdomains
that you didn't think of at the time that
you didn't include in the search.
And users are going to get a certain
error in their browsers when they go to
those subdomains.
And so there's a lot of complexity and
there's a lot of purely administrative
difficulty in keeping these things up to
date, keeping these things deployed,
remembering which cues are
for which sites, which certs are for
which sites.
Where does that go in the Web server
configuration, all of this complexity.
We believe that overall this
is the biggest barrier to adoption on
the part of people who have an interest
in making a secure Web site.
And this is the barrier that we intend to
address and eliminate.
So we've created this project called
Let's Encrypt, and this is a
collaboration.
And we started working with the
University of Michigan on
the idea.
We started about three years ago working
on the idea that there could and should
be a completely automated certificate
authority that can issue
certificates to anyone
quickly at no charge.
And we worked on this project for a
couple of years and we happened to learn
that Mozilla was actually working on the
same project in parallel.
So fortunately, we were able to combine
forces and be
stronger and more effective together and
have a single project among these three
organizations to
bring this vision into practice.
And the vision is also that
we should be better than the existing
CERT authorities, at least for
the portion of the Certificate Authority
space that we occupy in every
way. We should be cheaper.
We should be easier to use, we should be
more convenient and we should be more
secure.
And for our launch, we have commercial
partners, Akamai and Cisco.
And I don't trust and thanks
to them, it's going to be possible for us
to have publicly trusted certificates
that will be accepted by browsers.
So just to be clear about that point,
thanks, just to
be clear about that point, this is the
question that we got the most.
Are users going to have to install
something in their browser in order to
accept your search?
And the answer is no.
The users browsers will trust our cert
authority and its certificates out of the
box.
And for people who aren't familiar with
the intermediate
mechanism, a certificate authority can
delegate its power to another
CERT authority by issuing
a certificate that says this other
entity is also.
And this is something that happens
routinely on a large scale.
We have another project called the SSL
Observatory that showed that, in fact,
there are hundreds of entities that have
hundreds of names, that list of entities
that have had this power delegated to
them by certificate authorities.
And in fact, normally when
you get a certificate for an identity
for a website, it's almost always signed
by an intermediate certificate authority,
not directly by a root certificate.
Authority or authority will
be cross signed by I then trust, meaning
that trust will delegate to us
this
ability to be recognized as a certificate
authority, which means that mainstream
browsers will trust our certificates
immediately.
So within the Kyuki, there
are various forms and levels of
validation that the certificate
authorities perform.
They verify or confirm
or validate different kinds of
information, depending on what
information they're going to put in the
certificate, the lowest level
of validation is domain validation
in domain validation, the certificate
authority says.
I checked that the applicant,
the person requesting the certificate
controls this domain name.
And in domain validation, the authority
explicitly does not confirm
who the applicant is.
They explicitly don't say
this is such and such an organization
based on such and such a city,
they say we don't know, but this
applicant controls this domain name.
There are other forms of validation that
certificate authorities do in the UK,
such as organizational validation and
extended validation, where they do, in
fact, say, we're going to go
find out about the human being who
requested the cert and we're going to put
other contact information and other
identity information in the search.
So an advantage of domain
validation is that since it refers to
confirming control to validate
and control of the domain name,
we believe that we can replace the
Certificate Authority with a very small
shell script.
OK, so actually, the industry has a lot
of rules, so the Shell script may not be
that small, but
and it may actually be written and go,
but,
uh, we have to comply with all of these
industry standards, right.
As a condition of being a certificate
authority. We have to actually go through
and have an audit.
We have to show what our procedural
controls are. We have to show what our
technical controls are.
We have to show what our policies are.
And so we're developing all of these
aspects, but.
The point that remains is that the
process can be fully automated
for the most common cases, it can be
performed by machines.
There doesn't need to be a human being in
the loop. And so that's what we're going
to do.
So just to describe a little further how
this works, you have your client
this is kind of confusing, like with the
ex Windows system, the server is the
client, right?
OK, you have your Web server,
which is the let's encrypt client,
which is connecting to the CERT
authorities server, using
an application that we expect will be
bundled with the server operating system
or maybe offered by a hosting provider
and they speak to each other, a protocol
that we're developing called ACME, the
Automated Certificate Management
Environment, and they talk about
the certificate issuance process and the
steps that need to be performed.
So to simplify the process a little bit,
we can say the client says, I
control these names and I want to search
for them.
And the server says, OK, in order to
prove that you should do this.
And the client says, all right, I've done
so, here's the proof.
And the server says, all right, here's
the certificate, and
in the coming case, it ought to be just
about as simple as that.
Army is Jason structured protocol
that's being developed.
It was primarily invented by our
colleague Richard Barnes at Mozilla
and it goes through each step
in the process of issuing a search
through DV.
Just to talk briefly about the
organizational aspect, we've
incorporated, a California nonprofit
corporation called the Internet Security
Research Group, or ISG, which is the
entity that will operate the Let's
encrypt CIA.
We're preparing for the audits and
the other process, other
processes that are required for the build
out of ACA.
And we're expecting to have the
ability to issue certificates to the
public around June of 2015.
So what we have right now is a technology
review. So you can get our code,
you can contribute to our code, you can
try out our code.
But just to
warn you, certificate's that you get
with our code right now won't be publicly
trusted at the present time.
We can only issue test certificates,
but we welcome people to experiment with
our technology and try out our
technology.
I wanted to talk a little bit about this
validation method that we've developed
called device and I and we think that
device, an eye is stronger in some ways
than the mechanisms that a lot of TV guys
are using today.
The basic idea is that the verifier
asks the applicant to post
a certain self signed shirt
containing certain information that the
verifier provides.
The verifier then makes an
appeals connection to
the server of the
applicant and checks that
that self censored is actually present
and actually contains the requested
information.
And if you have a live
HSDPA site, this doesn't have
to interfere with that site.
You don't have to replace your cert
with the sort of the site because we're
using the same mechanism server
name indication.
So when we connect, we'll ask
about a particular invalid domain
name. And the self-defined search should
be served in response to that request.
It doesn't get served in response to
other requests.
So, again, if you have a live site,
we won't interfere with your live
site. It can keep working just as normal
while we do this verification in
parallel.
And the bottom line of this is
that it proves control of the Web server.
It proves that you have the ability
to reconfigure the Web server that's
listening on that domain
to the point of posting new
certs.
And we think this is a very strong
validation method and we're expecting
this to be the primary or a primary
method of validation.
Again, users don't have to worry about
that very much because we're providing
client software that handles all of this
and we believe that client software is
going to be very convenient.
And that's really an essential part of
this vision.
We think it's going to be
at most this difficult
to get your cert
and it ought to take.
It ought to take less than a minute to
get the cert and install it.
So I want to show you a video.
I want to show you an excerpt from a
video that was prepared by
my colleague, James Kastin from the
University of Michigan, who's the primary
author of the client application,
and I'll try to narrate it and see if I
can keep up with what James is saying in
the video here.
But this is just a demo of the
client application as it existed a little
while ago. So the idea is you might have
a site and the site doesn't have it.
So when people go to that site, they get
an error, right?
There's an invalid cert or there's no
cert at all. So you have this let's
encrypt application and you say Sudo,
let's encrypt.
This is a warning that the search that
you get won't be publicly trusted, OK?
It passes your Apache configuration and
detects which virtual host you have
and it offers to get you certs for all of
the virtual hosts that you have.
And then it says, OK, I'm generating a
key, I'm generating a certificate request
and I'm connecting to the server.
And actually, while I was explaining that
it got the cert and installed it, so
it finished.
And it actually
it actually reconfigured a patsy and then
it asks whether you want to redirect
its GDP in that Apache configuration,
virtual host to its GDP or not.
Now, James is going to do this again,
showing that if you know exactly what you
want ahead of time, there's actually a
non interactive mode where you can just
say exactly what you want and then you
won't be prompted interactively.
So he's just saying
sorry.
Yeah.
So he just wants to assert.
For encryption example, demo,
and it generated the key, generated the
request, configured Apache
to answer the device and I challenge
received the challenge, got the cert,
deployed it and reconfigured Apache
with a V host that redirects the
HTP to its GDP.
So now if he reloads the HTP,
Apache redirects to its.
And so all of this is reliant, of
course, on the ability of the client to
pass and to write to the
Apache configuration and the
configuration files of other Web servers.
And that's an ongoing effort that we're
involved with to try to make this as
convenient as possible for people,
regardless of what server software
they're using.
I'm also working on a standalone version
which will just get the cert and save it
into a file.
So if you have some application,
some server that you want to install the
search into, that's not supported by our
software for automatic
configuration, you can just get the cert
and have it in a file in your directory
and then you can do what you want with
it.
So we will have a standalone mode that
doesn't require you to let
our software edit your Web server
configuration live.
But when it does edit your Web server
configuration, it has a very careful
configuration file backup mechanism
and check pointing and roback mechanism.
So it's not going to change your
configuration file and not give you a
copy of how it was before, you know.
And we care a lot about the security
of the cert system.
In fact, a lot of people working on this
project are people who've done previous
research and previous analysis about
concerns about the safety of the
Certificate Authority system and concerns
about the safety and security of it.
Yes, we're very well aware
of the risks of mis issuance.
We're very well aware of
the concerns that certificate authorities
could get tricked into issuing something
that someone could try to legally compel
them to issue a inaccurate
cert, that someone could try to hack them
and steal their key.
All of these are concerns that are
certainly very much on our mind and we're
not trying to minimize
them or sweep them under the rug.
We think that CEOs have a big
responsibility and
we want to be very careful with that
responsibility.
We think that transparency is a really
important part of this within the context
of the existing system.
And so we're likely to adopt something
along the lines of Google's CERT
transparency system, where all of the
certs that are ever issued by the
authority are published publicly,
and where we can actually say that if the
certificate has not been published
publicly, it should not be accepted.
And there are other mechanisms that we're
looking at and talking about in terms of
transparency, in terms of being able to
say to people, why did we issue
that search? What sites have we issued?
What do they say?
Um, we're also very interested in
exploring ways that we can decline to
issue things that there is some
reason to believe that we shouldn't be
issuing.
And so one policy that we're exploring is
if there is a valid search
already for a particular
name that's still within its period
of validity, we may say that
we won't automatically issue
a new search for that name
unless the applicant can prove that they
control the private key that's
in the existing search.
And so then we could say, OK, well, if
there is some HSDPA site out there
that's working fine right now,
we're not just going to issue a search
for that name to some stranger who comes
along who doesn't control the property of
that valid functioning HSDPA site.
And there are other mechanisms that we
can use where domains can say
we don't want your to ever issue
a search for our name and we can respect
that request.
So, again, we're very concerned about
avoiding this issue and exploring
technical means that we can use to
mitigate the risks of mis issuance.
We'd like to be really widely integrated
so that this is a really routine thing
that people can use conveniently and
expect to have them to rely on.
So we'd like to be in every server
operating system.
We'd like to be integrated with every Web
server application.
We'd like to be integrated with every
hosting and application platforms.
So we'd like to have a situation where
when you sign up for a hosting provider,
the hosting provider gives you a
single click or maybe zero click
mechanism where you'll get a
valid search from us if you want one.
And of course, our protocol is an open
standard that's likely to be submitted to
standardization at IETF and you
can implement the protocol in your own
software. You don't need to use our
software to request or obtain a
cert from RCA.
And so if you are or work with
a hosting provider and you don't
like our client or it doesn't fit your
architecture, you can write your own
client. Right. You can do
what you like.
You don't need to directly coordinate
with us. You don't need a contractual
relationship with us.
You can just get these certs from us by
speaking our protocol to us.
And we hope that people will do that.
If you are an organization that finds
this valuable and wants to make sure that
it can exist, we welcome financial
sponsorship.
But that's absolutely not a condition
or a requirement of integrating with us
in any way.
It's just something that you can do to
support Internet security.
So that's actually about it, I wanted to
acknowledge these are the folks
who've been working on the original
technical concept with us from Mozilla,
from EFF friend from the University of
Michigan.
And of course, as the project has
developed, we now have even more
colleagues from these organizations and
even some volunteers from outside who
are working on developing other aspects
of the CIA and other aspects of the
technology.
So it's a great collaboration.
You can go take a look at our
code, help develop it, help
test it, help critique it.
Um, we'd be very grateful for public
involvement. So thanks very much.
And I think we have actually
quite a bit of time for questions,
because I think that was only half an
hour, but I know people tend to have
questions about this project, so I'm
very happy to hear them.
So I thought you would speak a little bit
longer.
Yeah, but thank you.
And I think that actually a lot
of questions.
So maybe it's a good thing that you
have left or some time for this.
So is there a question from the Internet?
OK, let me start with this.
OK, first first question, does
this only work with Apache?
So it depends what you mean by work with
us.
So in terms of the ability to do what we
see in the video where you run
the program and it gets the cert
and then configures the cert on your
website automatically,
in the current version of our software,
Apache is the only thing that we've
integrated with yet in
that way.
And so today
you would only be able to have that
automated experience with Apache.
We're actively working on integrating
with Engine X and of course, we
want to integrate with every other Web
server. So we welcome other people to
help write that integration.
There's no technical reason that it can't
work with any and every Web server.
It just requires us to write the code
that deals with reconfiguring the Web
server in an appropriate way.
And that code, unfortunately, will be
different for each and every Web server
application.
OK, before we go further,
I see that we are sitting right
at the moment, but we have learned that
people try to stand up and go out
to the kitchen.
If you need to do so, please be quiet
and don't speak. And we will continue
with succession.
I think I start with
I don't know who was first.
I think I go one.
Yeah, that's you.
Yeah. OK, there are several
questions.
The first one, is there a possibility
to revoke a certificate and
what bring all the other commercial
theories about your work
on.
I'm actually sorry that I cut off the
demo video so quickly, maybe
I'll put that back on while talking about
this, because the next thing that happens
in the demo video is let's encrypt
dash revoke.
And it demonstrates revocation, which has
actually already been implemented.
Revocation is actually just about as
quick as issuance.
In fact, it may be faster because you
don't have to test,
uh, you just have to prove
cryptographic control of the name of the
subject's key and then you can
revoke. So, yes, revocation is already
implemented and is, of course, a very
important part of the public key
infrastructure.
And I don't think that we've heard
directly from any of the other case,
I saw that one person from one of the
other CEOs posted on a public mailing
list when this was first announced,
something like, um, well, I
assume they're going to comply with all
the industry rules. Right.
Um, and so far, that's the only comment
that I've heard from others.
Yes.
OK, well then I think to.
Thanks. Great stuff, I really look
forward to this ruling.
What are the rules of
the other partners, Akamai
and Cisco, in this work?
I think that their main role at the
outset is providing financial sponsorship
because they think this is important.
I'm hoping that they'll find it
technically useful as a thing
that will help their customers, but
their initial role is just allowing
it to happen financially.
Great. More people should do that
than the fall.
Um, can I issue a certificate
that's only valid for a few days so I
could forego the entire vacation mess
and
do it that way and issue
new certificate every few days?
So we have a lot of interest in the
proposals for so-called short lived
certificates, where
some people view that as an alternative
to XP.
And I'm sorry to throw out another
acronym that's not in the chart,
but there
is a lot of difficulty about how in
practice browsers should check
whether certificates that have been
issued are still valid
and a mechanism was created for that.
That doesn't work very well.
Um, is that an attacker can
defeat, uh,
and so an alternative might be issuing
certificates that have a very short
period of validity and that
might be much more convenient,
relatively with our technology,
because we have the ability to
install the new certificate
into the configuration on a regular
basis. We would have the ability to
provide automated renewal and automated
installation and updating of the
certificate. So I think that's something
that could be achieved more easily.
We have not finished making policy
decisions about how
or whether short lived certificates will
be used in our system.
So I can't actually answer the question
except to say it's something that we find
quite interesting.
And then there's another question from
the Internet. Yeah.
Is there a plan to address uses for
certificates other than titles
such as SS Age certificates
to enable peak usage with
S.H.?
I don't think that we'll be able to do
that before we address the primary
case with the webpage.
I, I think that
if this model proves to work
well, as we think it will, then
I Asaji would be very interested in
figuring out whether there are other
parts of cryptographic infrastructure
that we can help provide for the
Internet.
I think this case is going to be our
first test case and
this is where we're starting.
When we go to the three,
not sure if you know that currently
World Wide Web consortium, technical
architecture group, so the
tax preparers publishing the
finding about ETPs recommending
it, do you find it useful to document
it? And if there's already some
collaboration about what to include in
such note?
We're really grateful to the TFG
for making that recommendation.
We think they are totally correct and
very timely and
not sure what else to say.
But I appreciate that they said what they
said. And I appreciate that a lot of
people in the Internet standards
community are really starting to
say that cryptography is
a fundamental, essential part of Internet
standards and technology standards.
And it's not that you design something
and then you make the optional crypto
version. A few years later,
the crypto and the privacy features and
the security features should be a part
of the network protocols and the
communications protocols from the
beginning.
Yeah.
I think people here agree to this,
OK, then I think the six.
First, thanks again for the project
I'm really happy about.
So with this first word and also
support certificates for non
web like EXPE,
SMTP or whatever.
Yeah, so we've had some discussions about
that.
Um, it appears that
right now in most
Tillawi implementations, the same
certificate will be accepted
for any application.
In other words, the subject
entity is just a common name for the
domain name and is not explicitly
bound to a specific protocol or limited
to a specific protocol.
Maybe it should be according
to some security arguments, but it's not.
And so you have the ability to take a
certificate that was issued for
a Web server in some sense, if you
want to think of it that way and use it
for an exemption for use it for a mail
server.
And we expect that people
will be able to do that.
If someone wants to write a
patch that actually installs
it in other servers that you have on your
system, that would be useful
functionality.
I think a common case for people who
only run something like an exemplar
server is that they would run the
standalone client, which would
temporarily start a
listening process.
Listening on Port 443,
the CIA would perform the validation
with Port 443 and issue the CERT
and then the cert would be saved as a
file, which the system administrator
could then install in another service.
But again, if people want to help make
that process more automated, we'd love to
have that help.
OK, then the five.
OK, thanks for the talk.
Do you plan to support wild
card and multi domain name
certificates?
So for multi domain name.
Yes, we support that right now
and it works great.
You just request all the names that you
want in the server and it validates
all of them. And we actually have some
additional features.
For people who expect to have to
reissue the search with more names
or fewer names in the future, there's
a technical way to avoid repeating
the validation for each name, every time
you make changes to the search.
Wild cards are a more difficult case.
We don't really know
how to use the validation mechanisms
that we have now
to perform a validation that would be
meaningful and appropriate for issuing
a wild card cert.
It's a question that's come up quite a
bit, and
I think that the answer is right
now we don't know how to do it.
And so right now we are not going to do
it. And if someone wants to propose a
mechanism through which we
could safely issue wild card certs,
our board of directors would be willing
to consider that mechanism.
One thing that one person said at a prior
talk about that is that if
we can reissue a certain automatically
in less than one minute
with a different selection of names,
perhaps the argument or the necessity for
wild card service decreases.
If you say, oh, I have a new virtual
host. Well, that's all right.
I'll just take 30 seconds and add that to
my cert.
OK, then the question from the Internet.
Are you aware that Tara Rescorla
coauthored a standard that contained and
a back door?
So I'm definitely aware of that report,
and I don't
know a lot about the details
of that, but Eric is
a very active person.
So the reason that someone is asking me
about this is probably that Eric
is someone, I think, on this slide, who's
one of our colleagues who's working
directly on this project with us.
And Eric is someone who's very active in
Internet standards, is the editor
of The Standard and the chair of the Task
Working Group, and has a lot of
experience with
all areas of Internet standardization.
So I don't know the circumstances
surrounding that incident, but
my impression is that Eric was
asked to edit that document as a result
of his role as the chair of the Task
Working Group, and not because he
thought that that technology was a
technology that he personally recommended
that everyone use as
much as other people working in Internet
standardization have ended up with their
names as editors of a lot of things
like John Postell, who didn't personally
invent each and every standard but was
called upon to edit them and to issue
them.
Then the phone.
How does your effort relate
to using certificates from
DNS, as in DAINE, and what do
you think about that?
Is that something that might come
into play in a couple of years?
Maybe so.
A lot of people have been interested in
putting cryptographic using DNS
and there are a lot of mechanisms for
that.
There are different schools of thought
about whether it would make sense
to replace
certificate authority issuance
with.
Intense SEC delivered keys
or, um,
whether you would use it
sort of to limit
whether you use it as an alternative or
whether you use it as an additional
mechanism to confirm the information
in the search.
Um.
I mean, I guess the answer is that we
don't have a specific technical plan
about how that relates to our work,
and it's obviously an important
development.
Certainly if there are defense
mechanisms that are relevant to
issuance decisions, then we ought
to know about them and we ought to take
account of them, as I say.
Then the question from to so
thank you for this work, I really like it
fully automated systems have a tendency
to feel badly and
well. You've taken out two of the
non automated parts of CERT issuance.
So the human interaction and the
financial commitment, do
you feel confident that you've prevented
any bad failures?
So I think different people envision
different failure modes,
I mean, some people envision a failure
mode like a private key compromise
of the CIA and then some
people envision that failure mode, like
someone succeeds in obtaining issuance.
Um, I think
that existing DVE
series run the risk
of mis issuance if someone is able to
compromise
the site.
Because someone who's able to compromise
a seat can perform the D.V.
verification steps as if that
person were the legitimate operator of
the site.
And so there is a risk of mis issuance
there even today, right?
I think that we are confident that.
We won't make that kind of risk
systematically worse, the CIA system
always has the weakest link issue.
If you can compromise any CIA, you can
get that CIA to miss issue for any
name, even if it's entities
that have had no prior relationship
whatsoever, as in the Senate,
are compromised.
For example, there was no prior
relationship with Google, but they were
able to issue for Google.
So there's this really fundamental
weakest link issue.
So I think what we can say is that with
respect to the revalidation,
we don't think that there is a way in
which our design makes things any worse.
We think that our validation and our
transparency is stronger than
existing Devco.
Then from the fall,
you're already removing the hazards
for getting the cert and deploying it
and so on.
And would you please also remove the
hazards for creating the debris records
and maybe automatically of
some flag, just create the
record, which somebody can copy to his
name server configuration?
I think that would be very valuable.
Um, it's
often not the same server,
the like the Web server and the DNS
server. And so the
I guess you're just suggesting creating
the configuration that someone might then
import to another machine.
So I think that would be great and I
would welcome someone writing a patch for
that.
Then again, from the Internet,
is there a limit of requested sign
certificates per domain
or limit?
What's that a limit of?
Requested sign certificates per
domain.
Well, I don't know if you can ask for
clarification back to the person or not,
but is the question like
how many times you can
ask for a new certificate related
to a particular domain or
in a time frame?
So.
I don't think that we have any policy
developed about that right now.
Then the six.
Do you think that the CIA
did you think that Sharat horses were
trying to idea of Africa and
gift certificates
for free to their users or.
Sorry, I didn't understand the beginning
of the question that who would
do that share horses like one
and one are?
Oh, they shared hosting providers.
Yes, yes.
We would definitely really like that.
And we would consider it a very
appropriate and desirable
use of our services if those companies
would integrate with us.
And we would love to have conversations
with any and all of them or
second best. We'd love to be surprised
that when we launch, all of them
have actually already written it and it
already works.
So the first best case is that they tell
us the second
best case is that we launch and then we
find out that people go and get a shared
hosting account and they got
a certain from Let's encrypt, looks like
someone integrated.
So I see that you're wondering
what we have to wait.
Um, OK.
It's a six.
OK, then the five things,
first of all, yes, you can use
Web services certificates for mail
service. I'm doing that with DOT SSL
certificates.
And then my first question is,
how does the long run finances
look like?
For example, when are you going to accept
private donations?
And the second question is, will
you document and publish the
infrastructure this year?
So the second question, I'm not sure
which parts of the infrastructure will be
publicly documented,
the certificate authority
code itself.
Or at least a candidate version written
in gold has just been published last
week on our GitHub account,
so if you look at this GitHub URL,
you can find in some sense the code
itself.
There are obviously other parts of the
CIA infrastructure, such as network
configuration and data center
configuration and so on.
And I'm not sure which of those parts
will or won't be published when they're
finalized. Those parts are not
not decided yet.
The other question, I guess, was about
the long term finances.
And so we really encourage
people, if you.
Are an individual or an organization
that cares about this, um,
we welcome people to sponsor us and
become financial partners.
As you alluded to, we don't have a
mechanism for individuals to donate right
now.
And I think that that's something that's
likely to appear after the US government
decides on our tax status
because that determination is still
pending.
OK, can we have, again, a question
from the Internet?
Can I issue a search for a dot
onion domain?
That's a great question.
I just spent a long time at ATF in
Honolulu talking to people about that
question and we didn't answer it.
And there are a lot of folks talking
about that on the browser forum,
uh,
mailing list. So I find that question
absolutely fascinating and I don't know
the answer.
And then the three.
So did you plan to
include multiple networks
views into the verification
of the clan certificate, for example,
when you have
some DNS cache poisoning our local
network attacks?
Yes, so
just to restate the threat,
if someone is applying for a cert and
is able to compromise part of the
DNS or part of the routing
infrastructure, it would be possible to
redirect connections to a fake version
of a site and then the verification
would be performed with the fake version
instead of the true version.
And so one possible mitigation for
that is to perform the verifications
repeatedly from multiple locations
on the Internet so that it's more
difficult to use a single localized
routing attack or a single localized
DNS attack to cause
the validations to validate something
that's fake.
And yes, we do plan to do that.
We had an earlier proof of concept
version which used Tor
to perform multiple validations
so it would perform one directly
and then one or two via tor via
different exit nodes that were located in
different places.
I don't know whether or not we'll
use Tor as a part of the validations
in the future, but multiple validation
is definitely an intended part of our
design for exactly that reason.
And then the one do you see
that there is some threat against
your project, considering that
infrastructure to people
and also your organization is located
in the United States?
I think that actually about eight people
have asked me that.
If the Congress already
had, I welcome the question.
It's a very common question and a very
common concern.
You know, there's a lot of mistrust for
the US government and the US legal
authorities,
probably deservedly.
And I think
one answer is that every certificate
authority is located in and operates in
some jurisdiction.
And there are many reasons to be
concerned about each of those
jurisdictions.
There is a trusted certificate authority
in the People's Republic of China that's
operated by a Chinese
government linked entity.
In fact, we made a chart and we found
that there are certificate authorities
operated according
to their self-description, in
approximately 50 different national
jurisdictions, and each of those
authorities can issue search for any
name.
I know that the United States is one
that people have a special concern
about, and it's the one where we're going
to be located.
We're not going to be located in all 50
of those jurisdictions.
We're going to be located in the United
States.
I think there are basically
three reasons why
people might feel that this isn't as bad
as they first fear.
One is that the project,
perhaps unlike some other cert
authorities in the United States, is
run by a group of privacy
and anti surveillance advocates
and activists, some of whom
work in a law
firm with over a dozen attorneys
who are very interested in directly
fighting the government in court over
surveillance authorities and powers.
And who would I think, uh,
one of them can correct me if I'm wrong,
but. Volcom interesting opportunities to
go to court to.
Yeah.
So one of our attorneys confirmed
we would
welcome the opportunity to go to court to
challenge the government's ability
to compel
us to Massachusetts and so on.
And we may have more enthusiasm
about that kind of fight than existing
CERT authorities in the United States.
I didn't mean to miss issuing
of certificates or something.
I rather meant to terminate your
operation in some way.
Oh, I'm sorry.
I just assumed Miss Issuance because that
was the threat that other people had
mentioned.
I think that operating a certificate
authority seems to be lawful
and a lot of people do it.
And there seems to be some
it's a common line of business
for people to be in.
And I'm not aware of legal problems that
have encountered in terms of their right
to exist and to discuss.
Then the two.
Thank you. Do you have a recommendation
on how to lobby shared hosting providers
to pick up your service quickly and
cheap?
That's an interesting question.
I'm hoping that general
competition and awareness
helps with that, that some large provider
may say, all right, well, now this is,
uh, free or
just one percent extra or something as a
result of this service.
And then others may say, all right, I
guess we've got to do that, too.
I have certainly spoken
to one large hosting
provider that was very interested in
integrating our service.
So I think that there is a likelihood
that that will happen.
And I had a suggestion from someone at
the Congress to try to attend a major
hosting conference that happens in Europe
in the spring.
And so I'm hoping that will attend
a hosting conference and try to spread
the word there.
Do you think a letter or email
template for a request
to the shared hosting providers might
help, as a lot of
them equal looking
letters tuning in may
help?
So, I mean, I would prefer
in this context to start with approaches
through individual engineers
rather than having sort of a petition,
because I think it is something that
they'll start by viewing as a commercial
and a technical proposition.
And I think we can try to approach them
at an organizational level.
And then I think that competition will
help quite a bit with that.
Then the fall, um,
I wanted to ask if
you have maybe for about
working together with the existing CIA
is like, for example, Cassard,
because if I look at CIA
sort of certificate or class
one, certification is exactly
the same what you are actually currently
doing and maybe
with your scripts you are a little bit
advanced, but
why not work together?
Um, so.
I really appreciate the search school
and other people's goal of making
the certification
infrastructure a free
service that's equally available to
everyone.
I think that's exactly the right call and
that's something that we need.
And that's a reason that we're doing
this project.
Um, and I would
welcome people who want to cooperate
with us in some way to get in touch.
I think
CSIRO in particular has a particular
model and particular infrastructure
that is different in some ways from
what we're doing, although similar in
some ways and similar in terms of goals.
But I think basically we've
developed a very specific path
that we want to
get done quickly and start
issuing quickly.
Um, so
we're pursuing the creation of this new
idea because we think that that's a
fast way to reach
the goal of issuing publicly trusted
search to the public.
But if there are folks who have
experience in this area through case or
otherwise, who have proposals or
ideas, whether technical proposals
or proposals for collaboration, they
should definitely get in touch with us.
Well, uh.
Could I say something more?
Oh, come on, hear me.
Yeah, OK, good.
Now, um, well, as
far Myers, as far as I
are currently aware of the
new system at that is currently
being written and there are quite
a few changes in there and that will be
more or less, I'd say, in
a few parts of it, and that one could
maybe just put it all
together to one project.
Well, I think we should definitely talk
about it.
OK, then the six.
I have two questions, the
first question is, when you
reissue certificates or add
extra domains to these certificates,
does that include changing the private
key?
That's the first question.
Well, I don't.
I think I've ever thought about that.
I mean, there are other people who are
working on the protocol who presumably
have thought about that.
Um, the
common case that we were thinking of for
changing the certificates without
repeating all of the validation
is keeping the same private key and
adding or removing names.
And in that case, we think we can skip
performing the validation of control
of names that have already been
validated. If you can prove continuity
that you're the same entity that
contacted us before that we did that
validation with changing
the private key might turn out to be
a big enough change that
we would want to repeat the validation
to avoid the risk that it's actually a
completely different entity coming in
from scratch.
OK, so sorry, I have a
second question that ties into that if
you are continually
creating new certificates with the same
private key, the revocation
process becomes more complicated because
you have to revoke every single previous
certificate that was issued with that
private key if the private keys is
compromised. So that leads into my
question of how are you
planning to maintain a scalable
available revocations system
where OSPI has low
latency and chorales?
There's there's a lot of traffic that
comes along with hosting these services.
How do you plan on building
a network infrastructure that's able to
withstand that in an affordable way?
So with apologies to my colleagues, I'm
really glad that I'm not responsible for
creating the ISP responder because
I really don't envy people who have to
create EXPE responder's.
Having said that,
we're we know that
we have to have a lot of hosting capacity
to serve HSP.
We're going to have to estimate what that
will be and figure out where we
can get it.
And I think, you know, when you make
changes, presumably when
we issue a new cert will
automatically revoke the old one.
But that does indeed create a lot of
potential ASSP traffic
and a lot of data.
So I agree that it's a large scale
challenge, and I hope that my colleagues
find a great solution to scaling it.
OK, the last question, because the time
is up and you had to have an hour for
questions. Answers is from the Internet.
Have you guys been working on any
proposals for restricting a particular
certificate authority to
a particular top level domain?
For example, a European SEIA,
only four domains in Europe.
So I think in terms of the threat,
that probably would have been a good
measure to have in the certificate
authority system at the outset
and to more closely tie
the people who issue
the domain names in the first place
to the cryptographic distribution
process, because as people point out,
they're the ones we treat as
authoritative for the question of who
controls or who owns the name.
And so if they're the ones who know who
owns the name, they're the ones who can
tell whether someone who wants to
post a public key
is, in fact, the owner or not the owner.
Having said that, that's not the system
that got created back in the 90s,
the system that got created back in the
90s, although it has extensions
that do allow you to create name
constraints by default, has no name
constraints at all.
And so I don't
think we see
a direct reason or a direct path
for us to create or implement
such name constraints.
Um, for the
the general question of preventing
issuance for a particular name,
um, on the part of the
name holder as opposed
to on the part of the registrar,
there is a mechanism called CAA,
which I think is quite
interesting and which we may implement,
which is one mechanism where you can say
I only want this year
to issue certs for my domain name.
I don't want any other to issue
them.
That's something that the individual
domain name Holder has to do.
But it could be a useful security
mechanism, at least at the level of
preventing misjudgments, attacks.
OK, that was successful
and I think is.
Yes, forget the.