I'd like to welcome the stage now, Jeremy Rand.
Jeremy is the lead application engineer at Namecoin and a researcher on tour TLS interoperability.
He's talking about a technical deep dive deep dive into how Namecoin's blockchain can replace
a centralized certificate authorities to provide decentralized PKI for tour and regular web browsers.
We'll get started right away.
Thank you very much.
Just a heads up guys.
If we could go ahead and have everyone kind of pack in just a little bit closer to each other.
I know that we like to keep our distance, but we have a lot of people coming in and out during presentation.
So as long as there's open seats along the sides, that'd be super helpful.
Thank you everyone.
All right, without further ado, Jeremy Rand, everyone.
All right, till everyone.
Good morning.
I'm Jeremy from Namecoin.
It's going to be talking about adventures I had recently building a public key infrastructure on top of
Namecoin and tour.
Let's get started, shall we?
So I was going to tell you guys what TLS was, but Hendrick already did a great job explaining what TLS
was.
It's the SNHVPS.
The key point here for this talk is that TLS requires certificate authorities or CAs to establish trust.
And there's a problem here because the public CAs are a censorship risk.
They are centralized, trusted through parties.
Side hub had their certificates revoked at one point due to a copyright lawsuit.
Meanwhile, let's encrypt their base in the U.S. and they revoked certificates based on U.S. sanctions compliance.
And let's encrypt says themselves that they do this to about one website per month, which seems problematic.
Also, the public CAs are a wiretapping risk.
I think everyone here is probably familiar with the DIGINOTOR incident from 2011, where CA got compromised
and Iranian users got wiretapped.
You may not be aware of a different case in 2013.
The Saudi government approached Moxie Marlon Spike and asked to pay him to help them wiretap users
by legally compelling a public CA in Saudi or UAE jurisdiction to issue fraud insurance certificates.
This incident might explain why Saudi intelligence, according to New York Times,
then paid a Twitter employee to try to wiretap me in 2014, which might be because my TLS research threatened that CA-related efforts.
Perhaps unsurprisingly, the Trump Department of Justice declined to prosecute that wiretap back to violation.
So, are there alternatives to the CA system?
Well, in the DNS world, we have these things called TLSA records.
The idea is you look up a TLSA record for a domain name and you get back a public CA.
And you can then use that public CA as a domain name specific CA that can authenticate TLS certificates for that domain only.
And this avoids trusting the public CAs.
The problem then is that you're trusting the DNS registrars and registries and ICANN,
so you're really just reshapling the list of trusted authorities rather than eliminating them.
But what if we have self-authenticating domain names?
And what I mean by this is imagine you had domain names that are inherently tied to cryptographic material,
so that you can authenticate them without needing any third party.
Do these exist anywhere?
Why, yes, they do.
I think everyone here is probably familiar with tour on insurvices by now.
They're anonymously hosted, they're kind of slow.
But most importantly, they have this interesting looking domain name structure.
And that's basically an ed 2.519 public CA that's been stuffed inside the domain name.
And so the domain name is quite inherently linked to that public CA.
There's also a name coin.
Name coin is basically like the DNS, but one of blockchain.
It does not require tour.
And therefore look up, that was as fast as DNS.
For example, FederalistPapers.bit is an example of a name-point domain name.
And name-point domains are owned by a name-point address,
in the same way that bitcoins are owned by a bitcoin address,
it's the same address format.
And so yeah, I mean coin address is inherently tied to the domain name that it owns.
So what can we do with this?
Well, we could do something sort of similar to TLSA records,
but if we have a template in the domain names,
we're avoiding public CAs and also avoiding trusting the DNS.
So that seems like a win.
Now by the way, I know what some of you are thinking here.
Wait, why do we want to even use onion services and TLS?
Because onions are already encrypted, right?
So onions are encrypted sort of,
but TLS has better end to end security.
And what I mean here is onion service encryption is terminated at the tour
Damon, whereas TLS is terminated at the application.
This matters quite a lot in some situations.
For example, who an x has tour browser running in 1vm,
and this whole Damon running in another vm,
and those 2vm's mutually distroct each other.
They are in different trust domains.
And you might also have a web server running in 2vnx in the same way.
It doesn't have to be the client.
And critically, neither the client nor the server
will have any way to know whether the other has a threat model like that.
So you should probably assume that threat model could be active.
Another situation that happens sometimes is the tour Damon and the application
might have an insecure network connection to each other.
For example, a lot of websites run a tour Damon and an HDPS server
on different cloud infrastructure IP addresses,
so that you can access the onion service through the tour Damon
and you can access it directly via the HDPS server.
Similarly, you might run tour browser on a laptop,
using a tour Damon on a Wi-Fi router.
This is less common, but it is a thing.
And again, neither the client nor the server
has any way to know whether the other has a threat model like this.
So again, you should assume this could be a thing.
TLS also helps compatibility.
Coach, I mentioned this in the Acupotalk, a little bit.
Applications expect TLS to be there.
Web browser will show scary warnings that they don't have TLS
and they will restrict features as well.
Things like Webcam access.
Generally speaking, it's easier to just give applications
to TLS they want rather than trying to patch them.
Tour browser does have patches for this kind of thing,
but they are huge maintenance nightmare.
All right, so how do we get TLS limitations
to actually use self-authentic and indomain names for TLS?
Well, we can't use TLS a support and hijack that
because there are basically aren't any TLS limitations
that have TLS a support.
That feature has pretty much been rejected by the community.
Now, what we really want here is,
imagine we had a pluggable certificate trust API.
That could basically do what we want, right?
Well, sadly there is no web extensions API for this
because the browser vendors don't want it.
But there is another kind of browser add-on.
PKCS let them modules.
You've probably heard of these because this is how you add
smart cards or HSM's to a web browser.
What you may not know is that browsers like Firefox use
PKCS 11 as a database query API for TLS certificates.
As examples of this, Firefox ships with a built-in root C-A list.
It's on a file called libnssckbi.sl.
That's where let's encrypt commoto, et cetera, live.
And that's actually a PKCS 11 module.
Firefox also has a SQLite-based trust database called soft token.
So if you import your own C-A into Firefox, it gets stored there.
That's also a PKCS 11 module.
So how does PKCS 11 actually get used for this purpose?
So basically when Firefox sees a certificate that signed by a C-A
HSM herd of, it takes the issue or name of that certificate
and it passes that issue or name to the PKCS 11 module.
And the module responds with the full certificate of whatever
C-A that corresponds to.
What's an issue or name you ask?
Well, it looks very much like this.
It's basically a list of text fields.
So in this case, there's a country and organization and a common name.
Sometimes there are other fields like a serial number.
You may have noticed some things that are not in that issue or name.
There's no public key or signature because those live elsewhere in the certificate structure.
What that means is our PKCS 11 module can just make those up.
It doesn't have to match anything that was in the request of the browser sense.
There's also nothing in there about which domain names it's valid for.
That lives in the name constraint field, which is also elsewhere,
and our module can make that up as well.
Okay, so then, you know, if we get that issue or name,
how do we know what we want our module to make up for that particular case?
So what if we get a hint?
What if we put a hint in the issue or name of our TLS certificate?
So what we do is we stop a domain name into the common name,
some field of the issue or name.
We stuff a public key into the serial number,
some field of the issue or name.
And then we sign the public key with an onion service key or an name coin address,
and we stuff that signature into the serial number, some field as well.
So as an example of that, I have the screenshot here,
so I'm signing a message with a name coin address.
So as you can see, the message has domain,
www.federalispapers.bit, and it also has a field X509 pub,
which is the TLS public key that's being signed.
And yeah, it's a message or sign.
We've got a signature at the bottom.
So then, we can put that signature into an issue or name like this.
So as you can see, the common name, some field of the issue or name,
says www.federalispapers.bit.
The serial number is a JSON structure that has the public key and signature in there.
So the way this winds up, winds up working is our PKC system module,
checks that pub key and signature from the issue or serial number,
against the domain name that's in the issue or common name.
And basically our module confirms that yes,
the public key question really was signed by whoever owns that domain name.
And assuming that that check passes,
then our module returns a newly generated CA that has the given public key in it.
And our module up signs a name constraint for that given domain name,
so it's only bound for that domain name,
and it crosslines it with a locally trusted root CA.
And that's enough to make the TLS client happy.
So the way you would set this up is if you're trying to create a TLS certificate
for the server side, we have a tool called ncgencer,
where you put in a host name, in this case we're doing an onion service,
and this command will output a certificate chain and private key
that you can put into your TLS server like Cadi, for example.
And on the client side, you have to install a PKC system module in Firefox.
This is very easy. There's a security devices dialog for that.
And once you've done that, TLS with onion services and namecoin based authentication will work.
And here is an example of this working, so this is tool browser,
loading an onion service site with TLS, and it's being authenticated by the onion service key.
So it actually does work.
Now you may be wondering about compatibility here.
Any application that uses NSS or GNU TLS knows how to use PKC as well and to do this.
So that covers Firefox and Tor browser among other things.
But what about Chromium?
So Chromium looks up unknown certificate authorities using a totally different mechanism.
So Chromium checks a field called AIA or authority information access.
It does not check the issue or name.
Now the AIA field, as you can see in this example, it's just a URL,
where Chromium tries to download the missing CAs certificate from.
So we can actually stop stuff into that field in base of the same way.
We can run a local host HDP statement that responds to AIA lookups,
and we can stop the same metadata that we stopped into the issue or name into the AIA location.
And you get this very nice, long URL that accomplishes the same thing.
So when you combine PKC as 11 and AIA, that covers basically all major TLS limitations.
The one major outliers open SSL, it uses a different API.
We don't support open SSL's API yet, but it is very analogous to PKC as 11.
We expect it should be pretty straightforward to support we just haven't gone to yet.
So something you might have noticed here is tour onion services are using ed25519 keys.
Namecoin addresses mean while are using Bitcoin script, which is a non-standard elliptic curve,
which also has multi-sig and time-lock functionality added.
TLS limitations mean while only support ECDSA using standard nist curves.
But this actually works out fine, because the signature is being validated by the PKC as 11 module,
not by the TLS limitation.
So the TLS limitation doesn't care.
There's a couple of edge cases that apply to namecoin here.
Basically namecoin supports smart contracts, and in practice what that means is you can have multiple namecoin addresses
that simultaneously control the same namecoin domain name.
And you can also have different namecoin addresses controlling different subdomains of a namecoin domain name.
In practice the way that affects us is the issue or name or the AI or L have to encode which namecoin address
and subdomain were involved in that.
So something you may have noticed about the schema just described is we're not broadcasting these signatures to everyone.
These signatures are being conveyed inside the TLS handshake as part of the TLS certificate chain.
This is really important for scalability because TLS handshake bytes are extremely cheap,
whereas broadcasting stuff in say the namecoin block chain will be very expensive,
because everyone has to download that.
The onion service DHT is not quite as expensive, but TLS handshake byte for still cheaper.
And crucially this expensiveness difference because magnified once we start dealing with post quantum signatures like dilithium,
which will increasingly become common.
Okay, so I've covered TLS, what about other protocols like SSH?
So SSH does have this thing called SSHFP records in DNS, which work very much like TLSA records.
And unlike TLSA records, SSHFP records actually do have pretty widespread software support.
Open SSH support stays.
But the problem is that would require broadcasting those SSHFP records in either the namecoin blockchain
or the tour on your service DHT.
And as I just said, that's not great for scalability.
So can we keep that inside SSH handshake like we did with the TLS handshake?
So you may not know this, but SSH actually has certificates and CA's.
This is not a super common thing, it's mostly an enterprise thing,
but we can take advantage of that, because SSH certificates can have extensions in them.
These have a similar role as the issue or name or the AI field.
And so we can stop a signature into what SSH certificate extension.
Conveniently, Open SSH has an option called the known hosts command option.
Basically, you can configure Open SSH that when you connect to an SSH server,
it runs a command that you specify.
And the certificate it got into that command.
And that command can then choose to market as trusted.
So we made a command for that.
It shares most of its coding common with the P cases of the module,
and AI ADM on that I described for TLS.
I have an example here.
So here you can see that I SSH into a domain that I have test 10.bit.
And as you can see, it did not ask me to verify a fingerprint.
It verified on its own that the SSH certificate that test 10.bit was serving,
really did match what was signed by the main point address.
I'm so very promptly just asked me for a password.
Kind of cool.
Now, everything I've described so far works great in good scenarios.
What about if you have a disaster and you need to urgently revoke a certificate?
So P cases 11 does support query for evocation status as well.
The query is keyed by the issue or name as before,
and the certificate serial number.
You can put issuer in serial pairs in the name point blockchain
or the onion descriptor and P cases 11,
we'll be able to tell those or revoked.
For chromium and other things that use AIA,
we're honestly not sure yet.
We think we might be able to use OCSP in a similar way that we use AIA,
but that is to be determined.
We're not sure if there might be quirks that we're not aware of.
For revoking SSH host keys, this is pretty easy as well,
because open SSH passes both the CA pub key and the host pub key
when it's passing south to our command.
So we can check both of those against certification list
that's in the name claim blockchain or onion descriptor
and choose not to market as trusted if it is revoked.
Now, as I mentioned, we are doing stuff with onion services.
Tor users tend to expect anonymity.
They get very unhappy if they're not anonymous.
Tor browser has an anonymity feature called FPI, first party isolation.
Basically what this means is if you have two different browser tabs
that have two different subdomains of the same website open,
they will share our tour circuit.
But if you have two different tabs in Tor browser that are for two different websites,
they will use different tour circuits.
And any sub-resources for a given website use the same tour circuit
as the website they're a part of.
Now, the point here is this prevents ad networks
from tracking you across websites.
The problem here is if we're doing a name point look up
or we're looking up an onion descriptor, that can generate
some network traffic.
And neither PKS11 nor AIA had any mechanism to tell us
which first party domain actually corresponds to that request.
And so we don't only have any way to isolate things on different tour circuits
the way we want.
So how do we fix that?
So conveniently before the TLS or SSH handshake never happened,
Tor's control port API does notify us that a connection
to that host name is about to happen.
And happily the FPI metadata is available in that notification.
It's available there because we send an Apache to the tour
domain that added that metadata and the Tor devs merged it.
So thank you Tor devs, very much appreciated.
So what we can do is we can do that name coin or onion descriptor
look up at that time as soon as we get that notification.
We can just cache the result.
So we cache the domain and list of name coin addresses involved
at name applications.
At that point once PKS11 or AIA or SSH needs that information
for the notification, it can just query that local cache,
which produces no network traffic, which is also convenient for latency.
And yeah, that cache isn't isolated per se,
but there's not any state in that cache that can be used by website
to fingerframe you.
So it preserves in and anybody just fine.
So I do want to thank our funders for this.
We are funded by two different funding pools from NLNet Foundation,
the internet hardening fund and the next generation internet initiative.
These are respectively funded by the Netholens Ministry
of Economic Affairs and Climate Policy and the European Commission.
We're also funded by power of privacy and slifers.
So huge thank you to all of our funders for that.
Here is my contact info.
And yeah, if you have any questions, happy to take them.
Cheers.
All right, okay.
All right, see first question, perfect.
There we go.
Hello Jeremy.
I would like to thank you for your work since so many years.
I'm following the name coin since I would say almost 10 years now.
And that's amazing what you're doing.
Thank you.
I have a question regarding to the parallel world and the connection
of the name coin and, for example,
Ethereum, ENS services if they are aware of what you're doing with name coin
or if they are not implementing similar things,
well, you are collaborating in such fields.
So the question is about whether the Ethereum ecosystem is aware of what we're doing
basically.
If, for example, ENS naming system,
Ethereum is using the same technology as you are.
Let's see.
I'm honestly not sure whether any of the ENS people have any
or what we're working on.
We generally don't coordinate very much with the ENS people very much.
That said, if they wanted to use this code,
it should work fine for them.
I would expect.
I guess one concern there would be that last I heard ENS
doesn't really have any kind of lightweight resolver that doesn't involve
a fully trusted third party unless a missed something.
And so, you know, for things like tour that are very bandwidth constrained,
I would imagine that might be a concern.
But other than that, I would expect this to work fine for other blockchain
naming systems.
There's nothing specifically named way to focus there.
Thank you.
Okay, next question.
Okay, I'll meet you.
Yeah, I'll meet you up here.
Thank you.
Right.
I have kind of two questions, but the first question is,
would this certificate authentication flow work
if you are disconnected from the internet?
So what is your offline experience?
Okay, so the question is whether this works when you're
disconnected from the internet?
Yeah.
So, TLS in general,
expect you have a network connection to whatever server you're trying to get to.
If it's an onion service, well, you're going to need to have at least a connection
to tour to get to an onion service.
If it's a name coin domain, I guess you could have a name coin domain
that, you know, points to, you know, an internal LAN IP or something,
in which case, maybe that's a legit use case.
I haven't partnered a whole lot.
Generally speaking, name coin.
So checking the data that's attached to a name coin name,
it doesn't require that you have internet connectivity at that exact time,
but the blockchain is too stale.
I believe more than about two hours than it will start throwing warnings
because it figures well, we don't actually know if we're under attack.
But, yeah, like, let's say that that two hour duration is okay for you
and you are trying to connect to a LAN IP.
I would expect that to work.
I have not tried, but I think it would work.
You had a second question?
Are we good?
Thank you.
So my second question is about,
take away the name coin, TLD, and the bit coin,
the tour browser to stuff it's humor.
Actually, trying to fake a real-world domain name.
What would be the onboarding experience for a user who doesn't have this stuff
installed locally, like the PKTSS-11 module?
Would there be a way to capture that journey and make sure they could install it
as a way of accessing that service?
I'm sorry.
Your mic is a little bit soft.
It's hard to hear from here.
I'm asking about if you're trying to use this system for a normal domain name,
where you don't want to go through normal centralized TLD infrastructure.
And if there's a way of capturing an onboarding journey for normal user
who's trying to access your system,
then needs to be redirected somehow to the PKTSS-11 module installation or something.
Okay.
So basically, you're asking about the scenario where a user doesn't have this software
installed, and they need to know how to get to it, basically.
Yeah.
I mean, right now, if you access a bit or the onion domain,
and you don't have the main point or Tor installed, it's not going to resolve,
I would expect that whatever mechanism you can use for onion services
in general should work fine here as well.
So if you'd like that maybe a better question for Tor people,
but yeah.
All right.
And that takes us to our time.
If you have any other questions for Jeremy,
feel free to find them afterwards.
But we're going to keep things moving right along now.
So let's give it up one more time for Jeremy.
Thank you.