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