Okay, let's get started.
The final keynote of this year's false dim.
As some of the older ones among you might know,
you used to have to pay quite a lot of money for web server
to tell us certificates.
And as some of you might have heard of this famous saying,
I think Einstein said that everybody knows that
as it's too come to do something until somebody comes
who didn't know that, and then they do that.
And then these guys, I SRG represented by Josh Us here.
Well, they came, they created, let's encrypt,
which now serves massive amounts of web serverty.
Certificates.
Four free in an automated fashion.
And Josh will now walk us a bit through this 10-year-long history
of Latincript.
Thank you.
I'm Josh, I'm the executive director,
and one of the co-founders of Latincript.
I've been working on this for a very long time now.
After he's done, Michael, I'm very close to him.
All right, I'm going to keep it close.
Before we get started, I want to take temperature.
How many people have heard of Latincript?
Great.
How many people have gotten a certificate from Latincript?
Wow.
Great.
Good to know.
All right, this is a quick overview of what we'll talk about today.
We'll do a little for the people who don't know how to get to work.
We'll get through that very quickly.
Then we'll do some history infrastructure.
Then what's coming in the future?
And some of the things we feel like we've learned over the past 10 years.
So this is a three-slide, very quick overview of the web API.
Ideally, when you connect to a website, you use a protocol called TLS.
TLS plus HTTP gives you a GPS.
And TLS gives you two different things.
It gives you encryption, which is scrambling the bits on the wire.
It also gives you authentication, so that you are talking to the entity you think you're talking to.
It doesn't do you a lot of good to have encryption if you have no idea who you're talking to.
You're on the other side of the encrypted line.
You really need both of these things to be secure.
And digital TLS certificates are the mechanism for authentication in TLS.
It's how you know that you're talking to the website that you think that you're talking to.
And a certificate is a digital file that basically contains the four things at the bottom.
It contains the domains that it applies to.
It contains the cryptographic public key for those domains.
Some other stuff that we don't need to talk about.
And then a signature from a CA over that content.
So it's a CA signing and saying, these public, this public key belongs to these domains.
And you get these certificates from certificate authorities like let's encrypt.
But there are dozens to a hundred more out there.
There are many options.
And this whole ecosystem is called the web public key infrastructure or web PKI.
We have to make it complicated with the wording.
So that probably enough details to get you through this talk.
So before 2015, the web PKI was mostly made up of complex manual processes.
Even if you had the money to get a cert, it was a frustrating process for a lot of people.
It was also expensive.
And there were a lot of people out there who weren't really convinced of the necessity of getting certificates and enabling the HGPS.
And the result of all this is that about 39% of page loads use HGPS.
Now that's page loads.
But those page loads of 39% were really concentrated on a small number of very popular websites.
So the percentage of websites, we don't know what that is or how we would have calculated that at the time.
But it's a lot lower than 39%.
So not a lot going on in HPS in 2015.
So what's the problem then, right?
Everybody knows that if you don't use TLS, your data is visible.
That's obviously bad for some things.
But you can imagine a website where the data is not sensitive at all, right?
It could just be a joke with an image and you don't care people see that on the internet.
So it's not obvious to people that encryption should be used everywhere.
But the thing that I like to remind people is that traffic that is not encrypted is modifiable.
So even if you're visiting a website where the content is not important in terms of privacy,
you have no idea if the data that you are getting back and loading your web browser is what actually was sent by the server.
So you could be fed on anything from fishing, advertising, whatever else it is.
So the modifiability to me is really the biggest issue with not using encryption.
And before I started a lesson script, I worked on a web browser.
And part of what I supposed to do there is make the networking more secure.
And if the content you're loading is not secure, you don't know for sure where the data come from or if it's even the right data or anything.
Working the other parts of the network stacks, you know, it's not totally pointless, but it definitely feels like it, you know, it's putting bars on a house with no door.
So that really got me thinking a lot about what do we need to do it, like we have to solve this problem.
So we wanted a solution that would get the web close to 100% HGBOS.
And we were thinking, we want to get it done in five years or less.
That five years seemed like, you know, the fastest amount of time within the realm of possibility.
We didn't have a way to do this in one year for sure, but five years maybe.
And ultimately, it comes down to the fact that there are a lot of web servers out there.
And you're going to have to convince all of them to take some action.
And that's going to take a lot of time, no matter what that action is.
We did not want the IPv6 and DNS sec adoption timelines that was not acceptable.
And sort of get seemed to read the roadblock that seemed to be the issue.
It's not that hard to just flip the switch and engineer or Apache and turn on TLS, but you need to sort.
And that's what people are missing.
So we thought a lot about what what are we going to do here.
And the only feasible solution that we could come up with was to start a new CA.
And that's a lot of work.
So in that sense, it wasn't an ideal solution.
It would be nice if we could get a thought of something clever that got us to our goal in a faster and cheaper way.
But this is what we felt like we had to do.
So in 2013, we started planning.
In 2014, we incorporated a nonprofit, integrated security research group to be the sort of home of lots and
developed.
We got a bunch of great initial sponsors.
And you know, these sponsors were really important to us.
Like these people saw the vision and believed in what we were doing way before it became a reality.
And I give them a lot of credit for that.
So we spent a very frantic year starting to build a CA.
And I did not know how to build a CA when we started doing this.
I had to spend a lot of time on the phone of people who knew what they were doing.
It was a bit overwhelming at times.
We got there.
And we announced lots of encrypt when we were far enough along that we thought, yeah, this is really going to happen.
And then in 2015, we issued our first certificate.
So fast for over today, we've had a lot of growth.
We're serving about 500 million websites.
And because each certificate can have multiple websites on it,
there's a slightly lower number of certificates.
That's the bar in the middle.
And then the green one at the bottom is registered domains.
So that would be the TLD plus one.
Whereas sort of an active is like including all sub domains.
So there's been a lot of growth.
We've come a long way since 2015.
And the web is much more encrypted than it used to be.
So this is what our infrastructure looks like today.
And we'll start with the organizational infrastructure.
So ISRG has about 25 staff total.
And that includes engineers, fundraising,
comms, finance, management.
We have three profits, lots of encrypted, which is by far our most well-known one.
We have another one around data privacy,
metrics, privacy called Divyup.
And we have a third one that deals with memory safety for critical infrastructure.
called ProsMO.
And the total budget for our org is about $6.7 million for a year.
And we get a lot of our funding from corporate sponsors, individuals, and some grants.
Now I'm going to focus just on the Let's Encrypt CA infrastructure.
So it's operated by 12 engineers.
It's a lot or a little depending on you look at it.
I tend to think it's not that many engineers.
I think we've done a pretty good job of trying to keep our costs low here.
But three or four of those 12 in a given time are running CA software.
And the rest are operating infrastructure.
They're essentially SREs.
And they're of course supported by the rest of the staff and the organization.
For a physical infrastructure, we have about three full racks of hardware across two different locations.
That's HSM's hardware security modules.
Compute servers, database, networking and stuff like that.
Physical security is a bit more intense than a normal data center.
We're in data centers that we share with other people.
But we have more secure situations than our normal.
Extra layers.
We do use the cloud, but only for some ancillary systems.
All of our core issuance and stuff comes off of our own on-prem servers.
That's required by the rules for being a CA.
You can't use the cloud to issue certificates.
But even if it wasn't the rule, I think we would still do it.
It's pretty cost efficient and it's worked out well for us.
We use a CDN.
And some of the spaces that we have, the physical spaces, also accommodate key ceremonies,
which is where we need to generate the route and intermediate keys for the state of authority.
We take a lot of care about visibility, EM radiation, things like that when we're generating keys.
This is our software stack.
Most of it is pretty common stuff.
At the bottom there, we write our own CA software.
It's called Boulder.
It's open source.
We've also been trying to move some of what we do to more memory-said code.
Our CA software is written in Go.
It's memory-said.
But a lot of the pieces of our infrastructure are not memory-said.
And we'd like to get there.
So we're focused on some of the most important components.
We started with NTP.
That's like an easy, a relatively easy place to get going in and introduce a new program into the system.
We have it working great.
The trifecta tech foundation is doing a great job maintaining that software that we built with them.
It's working great.
A lot of some crypts.
Later this year, we're going to replace our C-based DNS resolver with a memory-said DNS resolver called Hickory DNS.
We're going to swap out open-s to cell and friends for a Russells as well.
And then we're in the beginning stages of figuring out a better solution for a reverse proxy.
So I'm glad that we have a memory-said strategy for the org.
It's going to take years to execute on.
But a few years from now, most of our critical commands will be memory-said.
So the output of all this infrastructure that I just talked about is that we issue about six million certificates per day.
That covers about 500 million websites over the lifetime in the days.
We handle just some other numbers for OCSP.
It's a protocol for checking on revocation.
We do 15,000 requests per second at the origin.
139,000 requests per second at the edge.
It's like 80 something billion requests per week.
And we also run certificate transparency logs for a lot of encrypt.
But we also accept sorts from other CAs.
And the cost of lots encrypt, you know, separated from the larger organization of budget is about $4.5 million a year.
So I'll talk about what's coming.
Some of the changes we're making.
Since we started to be issued certificates with a lifetime of 90 days.
At the time, a lot of people thought that was short.
Now it's, I don't know, something close to standard, right?
People have, the rest of the industry has moved more towards 90 days.
But we're about to introduce the option to get six days certificates.
There are a lot shorter.
If you're automated though, this shouldn't really be an issue.
You renew your certificate every two or three days.
And then if something goes wrong, get a few days to fix it.
We're doing this because shorter lifetimes are better for security.
He compromises pretty common.
It's not always just, you know, malicious actors hacking into your stuff.
Sometimes you just mess up with get and upload your private keys to get have and now you have a problem.
So shorter lifetimes mean that, you know, if you do have a key compromise issue, you recover a lot faster.
No, people aren't going to be able to use your cert for as long.
We're also going to add IP address support.
So right now, you can get certificates for domains only.
But once we do this, you will be able to use TLS against an IP address.
You won't need to domain name at all.
This will only be available in the six day sorts.
We don't want to enable this for 90 days sorts because IP addresses tend to be a bit more transient than domains are.
So that's another reason we want to get some shorter lifetimes out there.
I don't, honestly, I don't not totally sure what the demand is.
We know there's going to be some demand for this, but I'm very curious to see how many people actually use this.
Another change we're going to make is we're going to end OCSP or support.
I think it's not a very well-loved protocol.
I don't imagine too many people are going to cry for this.
We're excited to not serve 84 billion responses a week.
It's going to save us time and money.
They also take up a lot of our HSM capacity when you think about the cryptographic signatures that CAs need to do.
OCSP dominates for us signing OCSP objects as opposed to the actual certificates or maybe 20% of our HSM capacity.
OCSP is also a pretty problematic for privacy.
If you're using an OCSP enabled piece of software, every time you visit a website, it asks us whether the certificate is revoked from your IP address.
It means in theory, we could know the IP address of visitors to websites.
In reality, we throw that stuff out, but we don't want to know, we don't want that surface area there.
So we're going to turn it off and people who want revocation information can get it from certificate revocation lists or CRLs.
Instead, we're going to continue pushing hard on something we introduced a couple of years ago called Act Me Renewal Info.
And this is an API for knowing when you need to renew your search.
So the way most clients work now is they calculate a percentage of the search lifetime.
So if you have a 90 days search, they'll say two thirds of the way through or 60 days go get a new search.
That doesn't work that well when we have to for some reason revoke your search.
If you have key compromise with those compliance incidents or something, we need to revoke your search.
We feel bad about that because we can take your service down, we revoke the search.
With this, we can notify you before we're going to revoke the search for whatever the reason is.
And your client can get a new search before that gets pulled up from under you.
So it's a very important part of resilience for the future of the WebPKI.
If you, you should check if you're using lots and crypt as your client support ARI.
It could be a stability issue for you in the future and it's good to try to find when that does support it.
So I'm going to talk about some of the principles that I think have helped us be successful over the past 10 years or make it to 10 years.
A big one for us is simplicity.
All the WebPKI requirements, we can run it on a single machine.
It does have replicas so we can fail over, but we have not needed to shard or cluster anything like that yet.
That might change, like in the next couple of years we're probably going to have to change that.
We've grown to the point where a single machine we're not going to be able to do it anymore.
Even though the machine we're working we're talking about is very large, like we make it into that a bit later.
But it's a big expensive piece of hardware, but it can't handle the whole database by itself.
That has been great for us over the past 10 years.
As expensive as that hardware is, the staff time to manage more complex and clustered database situation would have been much more.
So we kept it really easy by just buying nicer hardware and having a single database machine.
It's a finalized example here is our website.
Our website is really simple.
It's just a static site built with Hugo.
We don't have security vulnerabilities, we don't worry about, you know, it's saved us a lot of time to do that.
So the next principle here is very related to simplicity.
We want to be efficient and we want to be efficient because it has our financial reality.
We don't have a ton of money to throw around.
It is not that easy to get more money.
So it's also the right thing to do.
We should do the most good that we can with the public benefit dollars that are entrusted to us.
And we think about that a lot.
So we don't want to be wasteful.
We think a lot about scaling.
You know, earlier we looked at a graph that goes up and up and up and up at the moment is looking, you know, somewhat exponential.
We cannot do that with our staff.
Our staff cannot grow at that rate.
So every year we need to get quite a bit more efficient so that we can have no to minimal new engineers while keeping up with more and more traffic.
So we started out with about four full-time engineers in 2015.
And now we're at 10 years later.
We're issuing far more sorts than we were back then.
And we have 12 engineers.
They're doing a great job.
Yeah, simplicity and efficiency are very related.
So I think the last principle here is transparency.
A good example of that is we started filing really detailed public incident reports all long time ago before it was really common to do that.
Now the industry has sort of moved to a point where it's required to do these things.
But back when we started doing it, it was not as common.
And at the time we sort of wonder like are we airing too much dirty laundry here and we wondered if it would lead to more or less trust.
But I think it showed that we really understand the problems.
And we showed exactly how we were stunned responded to those problems.
And the end it definitely led to more trust.
So let's work out well for us.
Another example.
Our open source CA software.
Doing it publicly has been great for the web PKI.
People can really see how this stuff works.
If you want to find out how a certificate authority functions and issues certificates,
you can go to this repository and you can find all the dirty details written up and go.
It also has helped our client developers in the ecosystem.
So we don't actually make a client for lots and groups.
The community does that.
And if they want to know what's happening on the server side, they can just look up the code and read it.
Here's some lessons.
The first one was just me by an engineer.
About a week ago.
Who's saying it's a very good thing that let's think of this not in the hot path of every TLS connection.
Right.
We give you a syrup but then you make a lot of.
Maybe it seemed obvious to you but it's not obvious to all people who designed systems.
There's one exception here which is that OCS P thing that we're going to kill off soon.
Many times in a connection people ask for OCS P data but we're going to get rid of that.
So if you're designing larger systems like a WebPKF something else thinking about whether critical components are or not in the hot path is really important.
This is an important.
A big part of why lots and groups possible.
Open standards can help.
What I mean by this is oftentimes you'll see people say like out of principle I want to engage with open standards or it's like a nice thing to do or it seems like.
The ethical thing to do or something but it's also actually been very helpful for us.
It's not just not just a good vibe.
So building on an open standard helps a community build a client ecosystem.
That's more vibrant than we could ever build ourselves.
We thought about building clients at the beginning of lesson crypt.
And actually we started to build on before we turned it over to FF and they built Serpa.
But we realized pretty quickly that on our budget with our resources.
There are so many deployment environments out there.
We're not going to be able to make a client that works for enough people.
We could never do that.
We can only succeed here with the community.
So we sort of switched our attention to making it as easy as possible for the community to enable them.
And building on an open API really helped with that.
This is sort of along the simplicity lines again, but we really have to focus on what's important.
You can't do it all, especially if you want to be efficient.
So we say no to stuff all the time.
We don't do OVE, we don't do EV.
We have some fairly limited support options.
The forum is really wonderful, but there's not the kind of support options that you might get from another commercial provider.
There's some other things on this list.
Thanks for watching.
First of all, no one that was dealing with this problem with me.
I knew how to build a CA.
I've got to create a legal entity, hire staff, figure out the CA's work, get trust in bail, the browser, raise a bunch of money every year.
It's an intimidating thought that that's the path you might need to go down.
And it's not really short and that network work, right?
You can get pretty far into this before you realize this is just not going to play out the way we wanted it to.
But sometimes you've got to do this to have nice things.
So I guess the point here is, if you see other things in the world that are missing,
it seems hard to do them.
Sometimes it's worth it.
You should consider it.
It was a lot of work, but it was not an insurmountable amount of work.
And it was totally worth it.
Billions of people experiences significantly more secure in privacy, respecting web now.
So this is our 10th anniversary.
We issued our first certain 2015.
And here's how you can help us celebrate that.
You can help us convince any remaining 9HGPS websites to make the switch.
You can donate plots and cook or get your company in response to us.
You can contribute to an acne client.
I would suggest that a very good task is to help acne clients implement that AI protocol that I talked about earlier.
You can help people in our community form.
People ask questions there or staff try to answer them.
But, you know, we do depend on community contributions to do a good job there.
And you can help make the next piece of public benefit and infrastructure the web needs.
So thank all of our sponsors.
We're very lucky to have them.
That's it.
Thank you very much Josh.
We've got a lot of time for questions so don't be shy.
Go ahead.
Hello, thanks for the talk.
I was wondering, say hypothetically, if everyone at some point switched from 90 days to 60 days, which is an understandable.
Wouldn't that add a lot more quickly than anticipated?
Yeah, so the question is, if everybody switches to 60 days,
we're going to have to issue a lot more sorts and we're ready for that kind of strain.
It is definitely true in something we think about a lot of these days.
I haven't done the math in a little while, but I think it's about if everybody switched today, which they won't.
But if they did, I think it'd be about 20 times many sorts.
I don't know for a rainy day.
We're going to slowly ramp it up.
We're going to issue some six day sorts for ourselves first.
Then we're going to enroll sort of a set of early adopters and see how that goes.
We'll ramp it up for there.
We will be ready.
The main constraint on scalability for us is our database.
There are so many thousands of rights per second happening on that.
Not to mention tens of thousands of reads every second.
So the database is always a scalability issue for us.
So the only question for us is does our database have the capacity.
We have a plan for adding it as we need it.
So quickly, if you're leaving, please use the doors in the back of the auditorium.
So don't disrupt the answering of the questions and do try to keep it quiet.
Thank you in advance.
Thanks for the presentation.
You mentioned the key compromises happen far more often than we realize.
Do you perhaps know any numbers or any data from where this assertion comes from?
That's a tough one because we only know about the key compromises that get reported to us.
And we don't usually have like our own live investigations.
We only know when people request revocation of a certificate.
We also don't know exactly why they did it.
Do they suspect key compromises or with actual key compromises or it's just some other reason
that are reporting as key compromises.
I don't really know the answer.
But one of the public ways you can see this happens more often than others is there are
There are people who go and told get a hover positurized looking for private keys and they find them way more often than you would think that they would.
I also sort of remember and tell them quote me on this.
But I think they remember that there are about six months ago we had about 35,000 revokes certificates.
And that doesn't mean they were all revoked because of key compromises.
But out of all the certificates we had outstanding it was 35,000, which is another one of those numbers.
It's a lot or a little depending on how you look at it.
But key compromises I think is pretty widely under-reported.
I think people's immediate response is not necessarily to successfully revoke a certificate.
So I don't think our numbers say too much about it.
Sorry I don't have a more clear answer.
Hi, I still have to trust other CA's.
And it's really hard to pin which CA each domain uses.
Do you think there is any solution to that?
Because lots of people want to say, oh, when I talk to this server, I'll always want to use only.
Let's encrypt CA and no other CA.
And it doesn't scale right now.
And I built Linux distribution so I can ship it for everybody.
Can I ask clarifying question, do you mean can you as a visitor to a website or acquire a certain CA's?
Or do you mean it's kind of website or acquire all these certain?
Both.
But ideally for clients to be able to self enforce it.
I don't know how to self enforce it on a like per website basis.
Certainly you can edit the trust list in your operating system and just delete all the CA's.
You don't want to trust.
Then I don't know how to do it on a per website basis on the client side.
And the server that side the answer is CA records.
This is my turn.
Okay, so I don't actually have a question.
I just wanted to thank you guys.
You are doing amazing shit and I'm totally grateful for it.
Thank you.
How did you get all the major websites to actually trust you?
So I couldn't hear the question very well.
How did you convince all the major browsers to trust you?
If you want to get trusted by browsers, you can go one of two routes or both routes at the same time.
One option is you can create or sort of get authority to make it compliant.
You can get an audit.
It's called a web trust audit to compliance audit.
And you can just apply to the root programs at the various browsers.
The major ones that everybody is concerned with are Apple, Microsoft,
Mozilla, Google.
I'm sure I'm forgetting one.
But yeah, you can apply to these four or five different root programs out there.
And then, you know, that'll take anywhere from a month to a few months to make a decision.
And if they agree to trust your route, then you often have to wait for that trust to propagate.
So like, for example, if you get trusted by Android and they ship your route in the next version of Android,
you have to wait for all the people who use them who have older versions of Android to update to a version that trust you.
And I would say going down that path, probably the fastest you could get ubiquitous trust is about seven and a half years.
You used to be 10. It's a little better now.
So if you're a new CA, you don't really want to pay the money to become compliant and then maintain compliance for seven years,
while you wait for your stuff to be trusted.
So most people will get to a compliance status, finish their audit, and then they'll get cross signed by another CA.
So you have to make a deal with another CA where they take a route that's already trusted, and then they cross sign your route, so that I mean,
anybody running across your stuff will trust you via that other CA.
That is, I mean, at a minimum, it's expensive, and it's expensive, not for random reasons, expensive because the cross signing CA is taking on the liability of your compliance.
So if you cross sign a new CA, and that CA becomes non-compliant, you are also non-compliant.
That's a big risk for an organization that's already trusted to take, so it's expensive to get cross signed.
It's hard to quote numbers that's really a bespoke situation.
In our case, we found an existing CA called IdentTrust that really understood what we were trying to do, and it was happy to work with us.
And so we got cross signed by IdentTrust in 2015 before we, well, when we issued our first publicly trusted search.
So we were trusted by one of these like widely trusted identity search.
And right away, and not only ended in September of 2024.
So we kept that cross sign for almost 10 years, and then we didn't renew it, because lots of cryptos now finally widely enough trusted.
All right, you mentioned that you don't have any idea how many people will adopt these six day certificates, but we do have a very large audience here.
First, wondering if we could maybe show some hands to figure out how many people in this audience would like to switch to six day certificates.
All right, who would use a six day certificate if you got it tomorrow?
All right, that's a lot of trust.
I mean, I'd say trust because really the issue is trust, most of the concern that people have is, you know, do you have time to renew a certificate of physical problem?
Or if the CA goes down, likely we've never been down for very long, but could be an issue. Let me ask one more question now.
How many people would use IP address sorts if they are available?
That's way more people than I thought, okay.
Do you ever fear that you will become a single point of failure for the entire internet, especially with the growing numbers you've seen, and do you have any plans or ideas about that?
I'm sorry, I can't hear clearly enough.
Do you have concerns that you might become a single point of failure for the entire internet at some point?
Not the first time I've heard this question.
I think there are enough organizations out there that have an interest in doing this that we are not going to become a single point of failure.
I don't know how many CA's is too few, but we've definitely been in a situation where we had too many, but I don't think it's going to come down.
I think there, you know, AWS Trust, Google Trust are relatively new entrants, they're doing fine. I don't think it's going to come down, which is lots in crypt.
I got one more comment about that though, because CA's are moving towards this really automated model on a standard protocol, if there was a problem right, it becomes much easier than it ever has been before for somebody to pick up the slack if somebody else stops.
Like, in theory, if one of the CA's, like, that's a group of somebody else that disappeared, somebody else can open up their API endpoint, you're acting me client that direction in your good shape.
So it's easier than ever, I mean, the web PKI in general is a lot more resilient now.
In a very early slide, you had a thing where you said you would want to migrate away from MariaDB to MayaSQL. Could you shed some light on that?
Yeah, we push, we push both of these things very hard. We once told, really be people, the metrics for database, and they were like, oh, that's the big one.
The reason we're moving is not because our problem with MariaDB itself, it's because we're going to need to switch to a more closer solution, and we're probably going to use the test.
And so we're doing switching from MariaDB to my SQL for the better of the test compatibility, not because of an issue, it's like how MariaDB works on its own.
In your personal opinion, what do you feel the biggest gap or area for improvement is in the security of the web PKI? What worries you?
The question is, what do I think is the biggest gap in security?
I don't know if this is security the way you mean it, but certainly AI that protocol I keep talking about, like the automated renewal of sorts of specific times that resiliency measure is important for the security of servers around the internet.
For CS themselves, one issue is the integrity of the validation process, so when we do a validation check whether or not you are the website that you say you are, there's vulnerability is something called a BGP attack, where people can use fake BGP notices to redirect traffic.
We've known about this for a while, there's a team at Princeton that can do it for you live and demand, not in all situations, mercifully, but it's a scary demo of you.
So if you've known about that for a while, we worked with that team at Princeton to develop something we called multi-perspective validation, which so if you get a certificate from Watson Cup today, instead of getting one validation request from our primary data centers, you'll get four or five or six requests.
And they're all going to come from different parts of the world and different parts of the internet.
And the goal here is if you use BGP to redirect traffic on one path, that's not going to work because you're going to have to pull that off on six completely different paths and different geographies all the same time in order to trick us into issuing your assert.
That is pretty effective, it's not perfect, but it's pretty effective.
The only way to be better about this would be ubiquitous DNS sec, but I think that's basically never going to happen.
And I'm not sure that it should happen, even if it was possible, DNS sec is pretty problematic in a lot of ways.
So one of the things we're looking at is to try to see if we can bring encryption to recursive DNS.
So it's not exactly the same set of guarantees that DNS sec gives you.
But if we and our recursive DNS lookups could get the authoritative servers speak essentially DOH with quicker DOQ or something like that, that would help us a lot with network attacks.
So a long answer, but I think probably my answer is the integrity BGP attack vulnerability.
For TLS to work, local time is important.
Can you help with adopting NTS, which is network protocol secure over NTP over TLS basically, or do you want to host a pool?
Because right now there's only like 20 servers on the internet.
IP search will help.
Yes, NTS adoption, it's basically HGPS, but for NTP.
There's some people here from trying to detect foundation, like I mentioned before, that maintain NTP software that we helped build.
It supports NTS very well, the more people that make the switch, the better we switch up, lots of encrypt.
I think they are helping add people to the pool with their NTP implementations.
So I agree, it would be a good thing to do. It is not the fastest moving ecosystem as far as I can tell.
Thanks. Before it's encrypt, certificates were hard to get, and they were expensive.
And so someone could say, well, if you see a green padlock on the address bar, that means the website has paid for the certificate, and therefore it's trustworthy.
That could have been maybe used as an argument against democratizing these certificates.
I think the argument is 40, but maybe you did encounter it when it's encrypted, did you encounter it?
I'm really sorry, I'm having hard time hearing the questions, like fuzzy kind of.
Before it's encrypted, people could say that the padlock meant that the website was trustworthy, because it was expensive to get.
Sorry, I just can't make out the question, I can't hear well enough.
Sorry.
Yeah, I think there has been skepticism about, can you trust a free certificate as much as you trust a paid one?
It's definitely come up. I heard a lot from about 2015 to 2018, 2019, but I think I haven't heard too many complaints about it in years.
The browsers did a lot of good work with their interfaces to clarify things for people.
Some of the browser UI is back in 2015.
I think created more confusion than clarity.
So I credit them a lot with clearing that situation up, and I don't hear about it much anymore.
Thank you.
I lost you. Thank you.
I was wondering about the post quantum crypto era.
Are you worried that it will give you more work or give your systems more work or your people?
Yeah, so the question is, I think, what are we going to do about post quantum stuff and are we worried about whether or not it will work?
In the context of TLS in general, the most important thing to do is have post quantum hand shakes for TLS or key exchange.
That's available now.
Certificate authorities like us, we don't need to do anything about that.
And that's sort of okay because the reason you want PQ hand shakes now is that people can't save your TLS data now and decrypt it later.
But whether or not we do post quantum doesn't change that fact.
It's only useful at the moment of authentication.
So we don't really need to do it as a PQI too far in advance.
But there are people who have an opinion that is going to take so long to do that we should get started now.
I don't know, ultimately comes down to the size of the certificates.
If you have a post quantum certificate, the signature is much longer and it can break handshake packets and TLS into multiple packets and introduce latency.
And there are a lot of people out there correlating, you know, tiny fractions of a second with millions of dollars of income or something like that.
So there's a lot of concern about doing it now.
And if you don't panic about it yet, even if it was something that we wanted to do and the standards allowed it, which they don't allow it.
At this point, like CA's aren't allowed to use post quantum signatures, it's not included in the set of allowable algorithms.
We have a ways to go before we actually could.
So for example, we generate all of our root and intermediate keys inside of HSM's hardware security modules,
basically like special computers up protect private keys.
And those things don't support post quantum algorithms yet either.
So even if we were going to do it, we don't have HSM's that can do it yet.
And not only do we need HSM's, we need HSM's that can do tens of thousands of signatures per second,
which means hardware implementations and I can do that on a CPU.
So there are a lot of steps between us and getting there and there's a lot of debate about how quickly we need to do that.
And personally, I think we just need to wait a little while for the algorithms to work out,
see if we can make the signatures smaller.
I don't think it's an issue too much at the moment.
We can perhaps do one more question if anybody's got any.
One more.
Okay, we go one.
Do you think that there will be someday something similar to let's encrypt for email communication and encryption and stuff like this?
What kind of communication encryption?
For emails.
Email.
Yeah.
We got that.
That comes up a lot with this crowd.
I think the reason I assume you're talking basically about SMI and certificates and whether or not we might issue those.
It's quite expensive to add a new compliance regime and another system right simplicity.
So we try not to do things that require a lot of work until we're confident that they're going to be widely adopted.
So right now, as much as this does not make some people happy to sit here, I think SMI is kind of a niche thing right now.
Not that many people use it.
I think we would need to understand that there's a plan for a lot wider adoption to make it worthwhile for us to get into that game.
I think we all know who the major providers are.
I think they're going to have to be a part of that plan.
So we need to clearly understand that there's a path towards wider adoption and there's a path towards.
You know, a lot of people using these certificates that we make them available.
I think it's possible for that to exist.
I'm not too much personally in the email world, so I don't know how likely it is.
We'll have to see. I don't know.
But yeah, it really boils down to whether or not we believe it can break out of just being a niche technology or not.
Thank you.
That's all. Thanks.