17:07:29 <morganava> #startmeeting 2025-08-06 Applications Team Office Hours
17:07:29 <MeetBot> Meeting started Wed Aug  6 17:07:29 2025 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:07:39 <morganava> sorry about the delay, the meeting disappeared from the tea mcalendar
17:07:49 * Jeremy_Rand_Lab19[mds] uses my phone's "Clock" app and a .txt file as my calendar
17:08:21 <Jeremy_Rand_Lab19[mds]> Apparently stone-age tech isn't totally useless?
17:08:29 <Jeremy_Rand_Lab19[mds]> anyways
17:09:23 <morganava> apparently :p
17:09:56 <Jeremy_Rand_Lab19[mds]> yeah so my efficiency has been a tad lousy the last week (still...) due to some meatspace drama, but I made some progress on onion TLS things
17:10:17 <morganava> oh fun
17:10:20 <morganava> and also not sof un
17:11:23 <Jeremy_Rand_Lab19[mds]> In particular, the various repos I maintain for the onion TLS stuff just merged two nontrivial PR's a few hours ago, which decrease the size of the data that would need to be stuffed into an onion service descriptor (or the Namecoin blockchain, as it may be, since that code is identical between the two)
17:11:54 <Jeremy_Rand_Lab19[mds]> Was previously 90 bytes for a TLSA record, now it's 54 bytes
17:12:34 <morganava> what does that mean in practice?
17:12:41 <Jeremy_Rand_Lab19[mds]> (My assumption is that 54 bytes is trivial for onion service descriptor purposes, although there are further optimizations possible)
17:12:44 <morganava> apart from smaller data is more good
17:13:35 <Jeremy_Rand_Lab19[mds]> morganava: so basically, the design that Q and I agreed on is that we'll be able to put arbitrary DNS records into onion descriptors. TLSA records contain a TLS pubkey (or a TLS pubkey hash).
17:14:29 <Jeremy_Rand_Lab19[mds]> Prior to these PR's being merged, my code was using a full TLS pubkey, because mainstream TLS implementations like Firefox didn't like pubkey hashes
17:14:44 <Jeremy_Rand_Lab19[mds]> Now I'm using a SHA256 hash of a pubkey, because I found a good way to get TLS implementations to play well with that
17:15:23 <morganava> oh neat
17:15:36 <Jeremy_Rand_Lab19[mds]> yeah, and that leads to the secondary benefit of this
17:15:38 <Jeremy_Rand_Lab19[mds]> Which is
17:15:49 <Jeremy_Rand_Lab19[mds]> When PQ sigs become common for TLS in the future,
17:16:03 <Jeremy_Rand_Lab19[mds]> The pubkeys will get very big. Like, multiple KB per pubkey
17:16:29 <morganava> that seems... excessive
17:16:31 <morganava> why are they so big?
17:16:32 <Jeremy_Rand_Lab19[mds]> The fact that I've switched these to hashes means that we won't see a ballooning in onion descriptor size as a result of TLS transitioning to PQ sigs
17:16:49 <morganava> oh PQ as in post-quantum?
17:16:57 <Jeremy_Rand_Lab19[mds]> morganava: Basically, elliptic curve math gives you very small keys, but they're easy to break with Shor
17:17:01 <Jeremy_Rand_Lab19[mds]> yeah post quantum
17:17:17 <Jeremy_Rand_Lab19[mds]> The main contender for PQ sigs is Dilithium
17:17:34 <Jeremy_Rand_Lab19[mds]> Dilithium has much much bigger keys than either ECDSA or RSA
17:18:03 <Jeremy_Rand_Lab19[mds]> So, I did some testing to make sure that my hash trickery won't die when the pubkeys are very big
17:18:51 <Jeremy_Rand_Lab19[mds]> I determined that the max size of the pubkey I can use (while only putting a hash in the onion descriptor) is about 64 KiB (with the TLS implemention I tested -- I will test others later)
17:19:04 <Jeremy_Rand_Lab19[mds]> 64 KiB is easily enough to handle Dilithium; we probably won't even need 10 KiB when Dilithium is a thing
17:19:18 <Jeremy_Rand_Lab19[mds]> So, yeah, this scheme should work fine even in the PQ era
17:20:19 <Jeremy_Rand_Lab19[mds]> Anyway so yeah that is the mad science that I spent the last week on
17:21:51 <morganava> and what will this all give us in the end w/ regard to nion services?
17:21:57 <morganava> to onion services*
17:23:01 <Jeremy_Rand_Lab19[mds]> morganava: so basically, you'll be able to put a TLS pubkey hash in your onion descriptor, and you'll then be able to use that pubkey as your own private TLS CA, which can issue TLS certs for your onion service, without relying on Let's Encrypt or any other 3rd party, and the resulting TLS certs will work in mainstream TLS implementations such as Tor Browser and Brave
17:23:49 <morganava> ah there it is
17:23:52 <morganava> v cool
17:23:58 <PieroV> +1
17:24:18 <morganava> do you have plans to work on tooling after so onion-services can make ther required files for their apache or w/e deployments?
17:24:23 <Jeremy_Rand_Lab19[mds]> yeah sorry lol, I should have said that part at the beginning I guess
17:24:41 <morganava> :3
17:25:51 <Jeremy_Rand_Lab19[mds]> morganava: so I guess I don't actually know what tooling server operators will want. I should probably talk to Q and Rhatto about that (anyone else I should poke?), but for the time being I'm mostly focused on the client side of things (i.e. making sure that the certs are accepted in mainstream TLS clients), server UX would come afterward
17:26:13 <morganava> yeah those would be the two main people i think
17:26:39 <Jeremy_Rand_Lab19[mds]> alright cool, yeah I owe both of them a poke, so this can be one of the things we talk about
17:27:07 <morganava> :)
17:27:13 <morganava> it's good to see onion services getting some love
17:27:14 <PieroV> Jeremy_Rand_Lab19[mds]: btw, stuff changed in Firefox between 128 and 140
17:27:21 <PieroV> I think certs got merged in libxul
17:27:25 <morganava> i feel like they've been in the backlog forever
17:27:25 <PieroV> But I might be mistaken
17:27:36 <PieroV> I've read something in the various bugzilla tickets
17:27:49 <PieroV> That rang a bell, but I should look again
17:28:45 <Jeremy_Rand_Lab19[mds]> PieroV: yes I ran into that. As best I can tell, libnssckbi.so is no longer built by default (the default cert list is loaded from libxul.so), but if you put the file there yourself, it'll be used. Either way, it shouldn't affect us, because I'm adding an extra PKCS#11 module rather than trying to tamper with libnssckbi.so
17:28:59 <Jeremy_Rand_Lab19[mds]> It did break all the integration tests in my repos though
17:30:05 <Jeremy_Rand_Lab19[mds]> (gave me a bit of a heart attack when I was wondering why all my tests were failing due to a Firefox upgrade)
17:31:06 <Jeremy_Rand_Lab19[mds]> morganava: from my point of view, onions have been in my backlog because it was hard to get funding to work on them
17:31:17 <morganava> yeaaaah
17:31:23 <morganava> hmm
17:31:31 <Jeremy_Rand_Lab19[mds]> Now that Power Up Privacy is sponsoring me to work on this stuff, hopefully that's a sign of a broader ecosystem improvement?
17:31:47 <morganava> maaybe vOv
17:32:55 <Jeremy_Rand_Lab19[mds]> Anyway that's what I spent the last week doing.
17:33:34 <Jeremy_Rand_Lab19[mds]> (and with that, I'm going to run off to get lunch)
17:33:43 <Jeremy_Rand_Lab19[mds]> good chatting with you guys
17:33:52 <morganava> alright good chattign w/ you Jeremy_Rand_Lab19[mds]  :)
17:33:59 <morganava> have a good lunch
17:34:02 <morganava> o/
17:34:06 <Jeremy_Rand_Lab19[mds]> thanks :)
17:34:21 <PieroV> Laters Jeremy, have a good launch :)
17:34:27 <PieroV> * lunch
17:45:10 <morganava> alright good chatting
17:45:12 <morganava> have a good week folks
17:45:14 <morganava> #endmeeting