15:00:39 <pili> #startmeeting S27 03/10
15:00:39 <MeetBot> Meeting started Tue Mar 10 15:00:39 2020 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:39 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:40 <pili> hmm, hello meetbot?
15:00:43 <pili> there we go...
15:00:51 <pili> hi everyone
15:00:56 <pili> I hope everyone is having a good week :)
15:00:57 <brade> hi
15:01:14 <pili> here is the meeting pad as usual: https://pad.riseup.net/p/s27-meeting-keep
15:01:21 <pili> please add any updates and discussion topics
15:01:36 <pospeselr> hello
15:04:37 <pili> I'll give a few more minutes for updates and then we can start
15:06:36 <pili> ok, let's get started
15:06:57 <pili> is everyone ok with doing a quick check on where we are with the project so far? :)
15:07:20 <asn> ye
15:07:37 <pili> I have O1.1 v3 as default as completed
15:07:53 <pili> how is O1.2 looking? seems good from updates
15:07:56 <asn> yes
15:07:58 <pili> what's left to do on it? :)
15:08:08 <asn> i need to finalize the repository
15:08:10 <asn> where it should be
15:08:15 <asn> i talked with david today
15:08:23 <asn> we kinda decided to host it on gitlab.tpo, and with a mirror on github.tpo
15:08:25 <asn> i need to set that up
15:08:36 <asn> and then i need to write a blog post (the sequel of https://blog.torproject.org/cooking-onions-finding-onionbalance)
15:08:38 <pili> ok
15:08:40 <asn> to invite people to start using it
15:08:41 <pili> nice
15:08:43 <asn> i think then we can call this 100%
15:09:04 <asn> after some testing has happened im gonna release a new version of OBv3 and make packages
15:09:11 <asn> (im also gonna make a new release before the blog post)
15:09:12 <pili> we should include Onion Balance in our learning lab blog post also, if it happens
15:09:16 <asn> yes for sure
15:09:52 <pili> are all these releases alphas or are we already releasing a stable version?
15:10:08 <asn> of onionbalance?
15:10:13 <asn> there is no concept of alpha or stable in OB
15:10:21 <asn> it's currently in version 0.1.8
15:10:33 <asn> im gonna release 0.1.9 (first release with v3) for the purpose of the blog post
15:10:36 <pili> ah ok
15:10:39 <pili> sure
15:10:40 <asn> and then after testing im gonna release 0.2.0 for the purpose of packages
15:10:51 <asn> and release 0.2.0 is gonna overtake the old onionbalance in the pckages
15:11:02 <asn> im afraid of doing that now in case i break v2 support for people
15:11:31 <pili> hmm, ok
15:11:57 <asn> so yeah we can 100% this next week or the week after that max
15:12:04 <pili> great, thanks
15:12:16 <asn> the moment the blog post is out, we 100% it
15:12:40 <pili> moving on to O2.1 - client auth - I believe this is at 100% (minus docs)
15:13:05 <pili> I think for the purpose of this project we can call it 100% even though we don't yet have docs, they are in progress atm, thanks to c1e0 :)
15:13:16 <pili> any other comments before I move on to O2.2?
15:13:16 <mcs> yes, I think so. are there plans to add web pages soon or should we remove the “Learn more” links from the code?
15:13:37 <mcs> ah, in progress.  cool
15:14:39 <pili> ggus: and I need to discuss what soon means for us :)
15:14:40 <pili> we'd like to though
15:14:54 <pili> we're going to run a documentation hackathon at the end of March
15:15:01 <pili> and are hoping to work on these then
15:15:13 <asn> nice
15:15:53 <pili> ok, so O2.2 - typos, that's being worked on as part of O2.4
15:15:59 <pili> is it just waiting for review now?
15:16:04 <pili> or is there any other work pending?
15:16:19 <mcs> waiting on review plus merge
15:16:35 <mcs> plus translations once merged
15:16:50 <pili> great :)
15:16:58 <pili> ok, moving on to O2.3 then
15:17:21 <pili> that's onion-location
15:17:38 <pili> what's next for this one acat? :)
15:18:00 <acat> perhaps we need to have strings/translations? not sure if there's a ticket for that
15:18:21 <antonela> mcs: who is the reviewer of O2.2/O2.4? did we assign it?
15:18:35 <acat> i revised the patch to support <meta tags (apart from header) and simplified a bit, now it's on review
15:18:50 <asn> nice
15:18:53 <asn> did u also do the spec acat?
15:19:03 <asn> i might want to review spec, but i cant review the code
15:19:05 <pili> great
15:19:23 <mcs> antonela: acat and pospeselr IIRC
15:19:25 <acat> asn: i did not, but i can do it too
15:19:32 <antonela> mcs: super, thank you
15:19:45 <pili> acat: I guess it depends which files the changes are in and whether they get picked up automatically by emmapeel's scripts
15:20:25 <asn> acat: i think would be good
15:20:49 <pili> I'm still also trying to figure out if we need to do anything for #27502 and #30599
15:21:06 <emmapeel> if the strings are in the files we are already checking, they will get picked up. if there is a new .dtd file, you should open a ticket because i need to create a new branch, etc
15:21:08 <acat> pili: ok, i think i should also do a patch for torbutton.dtd for the strings
15:21:15 <sysrqb> pili: i sent an email to tor-talk@ asking about that
15:21:21 <sysrqb> but i haven't gotten any replies
15:21:29 <pili> sysrqb: yup, I saw, thank you for that :)
15:21:30 <sysrqb> so i'll probably just close those tickets
15:22:37 <pili> also #27590
15:22:38 <pili> I saw a few tickets recently that seemed related: #32777  and #33525
15:22:44 <pili> not sure if they're duplicates of #27590
15:23:49 <sysrqb> hm
15:24:57 <sysrqb> I have an idea for an easy solution for #27590
15:25:02 <sysrqb> but no one is working on that right now
15:25:10 <sysrqb> ("easy")
15:25:29 <pili> yeah, I need to review whether we want to do #27590 or not for this project in the end
15:25:32 <pili> let's move on for now
15:25:55 <sysrqb> i think it's something we can improve later, if it's not "required"
15:26:00 <pili> sure
15:26:04 <pili> ok, O2.5 - HTTPSE is the last one I guess
15:26:09 <asn> hm sorry
15:26:16 <asn> perhaps i missed O2A4
15:26:19 <asn> did iwe discuss it?
15:26:53 <asn> i'm wondering whats' the current state of #13410
15:26:58 <pili> oh, good point
15:27:02 <asn> i see pospeselr investigating the SOOC approach.
15:27:05 <pili> there's a bunch of other O2.4 stuff
15:27:09 <pili> let's go back to it
15:27:17 <asn> is it possible to get a summary of what SOOC is? i once knew but i have forgotten again.
15:27:22 <asn> and why we like it more than the "accept all self-signeds"
15:27:32 <pospeselr> yes though through a somewhat circuitous route than i would have liked
15:27:43 <sysrqb> we had a plan of discussing exactly this during this meeting
15:28:36 <pili> let's jump to that discussion
15:28:41 <pospeselr> alrighty
15:28:42 <syverson_> asn: you mean all for .onions yes?
15:28:51 <asn> syverson_: what do you mean?
15:28:57 <asn> yes
15:28:57 <asn> yes
15:29:05 <asn> "accept all self-signeds for .onions"
15:29:31 <syverson_> asn: i meant not for other than .onion addresses.
15:29:44 <pospeselr> so the tldr; for SOOC is that we skip the chain-of-trust checks that are normally performed on certs for onion sites, provided a few other constraints are met
15:30:02 <pospeselr> so that allows for self-signed certs and certs with an unknown CA root
15:30:29 <pospeselr> the 4 extra constraints are outlined here: https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt#L131
15:30:47 * antonela wonders who lives between self-signed certs and unknown ca root
15:31:24 <pospeselr> we currently have a patch which solely skips the chain-of-trust checks that i sort of came to independently before discovering the SOOC spec
15:31:28 <syverson_> antonela: the CA root is local here (I believe).
15:31:30 <asn> why do we want to allow "certs with an unknown CA root"?
15:31:44 <antonela> syverson_: right, that may be a case
15:31:45 <asn> and what does that mean? i'm not well versed into SSL
15:32:09 <pospeselr> also not well versed, but i'll try to explain
15:32:59 <pospeselr> so the SSL cert presented by the onion site is signed with another cert, which itself is signed, etc down to the root
15:33:18 <syverson_> For clarification: I meant local to the client, not the server.
15:33:31 <antonela> syverson_: si
15:33:50 <pospeselr> I *believe* (and someone correct me if i'm wrong here) that the browser has a list of root certs it knows about as valid cert issuers/signers and will throw up a warning if you get a cert chain with an unknown root issuer
15:34:06 <dennis_jackson> A mail to tor dev just highlighted this issue on the Let's Encrypt tracker: https://community.letsencrypt.org/t/if-when-will-le-support-onion-addresses/341/85
15:34:38 <syverson_> pospeselr: so far so good I think.
15:34:40 <dennis_jackson> If L.E. starts supporting DV Certs, is SOOC still needed?
15:34:59 <sysrqb> dennis_jackson: yes
15:35:02 <syverson_> dennis_jackson: yes. it's different cases.
15:35:03 <pospeselr> I think (?) that's to avoid impersonation attacks ie some rando issuing a cert for facebook.com that has all the valid bits but from an unknown issuer
15:35:23 <sysrqb> dennis_jackson: alec has a nice twitter rant on this, too
15:35:27 <sysrqb> *had
15:35:43 <pospeselr> since .onions are self authenticating/validating/whatever we don't actually need this extra restriction of the ssl stack for https onions
15:35:45 <syverson_> SOOC does not at all address connecting w/ registered or recognizable names.
15:35:56 <sysrqb> dennis_jackson: (such as: why leak the onion address to CT?)
15:36:39 <dennis_jackson> I did read the RFC: 5.3.1.  Potential negative consequences of DV certificates for Onion Addresses, but it just says TODO
15:36:54 <pospeselr> so I'm not a website person, so i'm not sure why you would go the route of using your own CA over just self-signing the cert
15:37:04 <pospeselr> but either scenario are equally secure as far as onion sites go
15:37:13 <asn> ok
15:37:24 <sysrqb> pospeselr: it has some valid use cases, but not many in this scenario
15:37:43 <syverson_> sysrqb: which scenario?
15:37:45 <sysrqb> like, you could create your own CA and then sign certificates for your website with that CA
15:37:55 <sysrqb> and then rotate your website certificate frequently
15:38:02 <sysrqb> but continue signing it with the CA
15:38:14 <sysrqb> the same reason why LE issues 3 month certs
15:38:17 <pospeselr> what would be the point of rotating yoru site's CA?
15:38:22 <pospeselr> er not the CA
15:38:22 <antonela> who does that in real life? why one does not simply self-sign?
15:38:24 <pospeselr> the cert
15:38:30 <syverson_> Ah, like in Richard Barnes's delegation?
15:38:30 <pospeselr> yeah that^
15:38:55 <sysrqb> delegation is another even-shorter rotation period mechanism
15:39:01 <sysrqb> but yeah, essentially the same
15:39:05 <sysrqb> as for who does this
15:39:07 <sysrqb> i have no idea
15:39:13 <asn> ok i trust alec to know that people do this
15:39:26 <asn> is it possible that SOOC opens up any security holes?
15:39:34 <asn> aka is it more complicated than simple "accept all self signed for onions"?
15:39:42 <pospeselr> it is more complicated than that
15:39:44 <dennis_jackson> imo: yes
15:40:00 <pospeselr> so sections 1.3 -> 1.6 outline a few restraints the cert must have
15:40:08 <pospeselr> which i won't pretend to understand the justification for
15:40:17 <pospeselr> but alecmuffet seems to think they're important
15:40:41 <pospeselr> asn: https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt#L131
15:40:45 <pospeselr> is literally 15 lines
15:40:55 <asn> but more constraints is good, right? less constraints is bad
15:41:02 <pospeselr> one would think?
15:41:09 <asn> like more constraints might cause bugs, but not security issues
15:41:17 <asn> ....except if compute security is not  as simple as that....
15:41:27 * asn looks at the sky
15:41:35 <dennis_jackson> It is also work for Tor, prodding NSS etc
15:42:20 <asn> given the lack of time and resources, would it be reasonable to just do "accept all self-signeds" which seems to be a subset of SOOC, and then in the future do SOOC?
15:42:33 <asn> we understand "accept all self-signeds" enough i think
15:42:48 <asn> but seems like we don't quite understand draft-muffett-same-origin-onion-certificates.txt
15:42:53 <sysrqb> i think "accept all self-signed certs" is essentially SOOC
15:43:03 <sysrqb> except SOOC explicitly says what this means
15:43:07 <asn> i see
15:43:23 <sysrqb> we would only want to accept a self-signed cert if it is valid for "this" .onoin address
15:43:28 <sysrqb> we wouldn't want it for any other address
15:43:30 <asn> ok i thought that the "unknown CA root" part of SOOC was causing the trouble
15:43:45 <syverson_> I think they're might be some worries about altnames that are not .onion, but I admit to also not entirely following.
15:44:04 <asn> sysrqb: i see!
15:44:09 <sysrqb> SOOC ignores the CA
15:44:18 <sysrqb> it only looks at the webstie, leaf cert
15:44:19 <sysrqb> it seems
15:44:27 <pospeselr> yeah basically
15:44:30 <asn> ok
15:44:38 <syverson_> sysrqb: yes, no altnames would address what I just said.
15:44:57 <pospeselr> i think that's covered in 1.5 and 1.6
15:45:01 <sysrqb> syverson_: yes, this is only valid for .onoin addresses
15:45:14 <sysrqb> syverson_: and only on the same .onion address (allowing additional subdomains of it)
15:45:38 <syverson_> wildcards? ;>)
15:45:39 <dennis_jackson> sysrqb: How will the code be managed for this?
15:45:50 <dennis_jackson> Will it be upstreamed into Firefox / NSS? Or Tor only?
15:45:52 <sysrqb> i guess this is where the "same origin" part o fSOOC comes in
15:46:06 <sysrqb> dennis_jackson: that is one of the outstanding questions
15:46:10 <sysrqb> syverson_: yeah
15:46:46 <sysrqb> and, i believe, this is as far as we've gotten
15:46:47 <pospeselr> asn: so in terms of work, i've done a fair bit of the legwork in terms of figuring out how to put this in tor browser, the bulk of the new/unknown work is figuring out how to extract the various properties we need to check from the ssl cert, and properly converting the prose into correct code
15:47:02 <dennis_jackson> I think this draft is very rough imo. Maybe it has a lot of potential. But it is unfinished and the security analysis is far from complete
15:47:11 <asn> yes i agree dennis_jackson
15:47:50 <dennis_jackson> For example, it relies on .onion being unique indicator of a Tor HS and of course .onion is reserved for this purpose
15:48:02 <syverson_> pospeslr: there may be code you can leverage from pastly's webext for SAT addresses (or that could be a red herring).
15:48:06 <dennis_jackson> But DNS is (in)famously unauthenticated.
15:48:12 <sysrqb> but it is a  design that can be analyized verses "allow all self-signed certs for .onion addresses"
15:48:31 <dennis_jackson> So what happens if bad ISP X starts returning DNS records for .onion?
15:48:52 <sysrqb> dennis_jackson: this should not be implemented outside of tor browser
15:48:56 <sysrqb> or a browser tht supports tor
15:49:01 <pospeselr> onion urls should never get to DNS to begin with I would think
15:49:10 <dennis_jackson> Okay, but then that is a barrier to Firefox and Tor.
15:49:13 <syverson_> dennis_jackson: that's a problem in general and violates the RFC.
15:49:19 <sysrqb> there is a RFC for that, but chromium does not implement it
15:49:41 <sysrqb> dennis_jackson: Firefox does implement it, and it is enabled by default
15:50:02 <sysrqb> pref network.dns.blockDotOnion
15:50:13 <sysrqb> (just fyi)
15:50:17 <dennis_jackson> Ah nice! Okay, that is good to know!
15:50:23 <sysrqb> so, i don't think that is a blocker
15:50:29 <antonela> right, let's try to shape a scope. We want to allow all self-signed certs for .onion s, maybe we want to first work in a proposal based on sooc but better? can we do it as part of this sponsor? or we prefer pospeselr to approach it and start a proposal from there?
15:50:44 <sysrqb> there is a question about uplifting this into NSS/Firefox
15:51:00 <sysrqb> and i don't fully understand Mozilla's opinion on this
15:51:13 <pospeselr> me neither
15:51:21 <pospeselr> i know they have opinions on how an implementation would look
15:51:45 <pospeselr> but i don't know their opinion on whether it's upliftable for them
15:52:23 <asn> (fwiw, i have another meeting in 8 mins)
15:52:32 <mcs> I think it is OK to ship SOOC in Tor Browser alpha while in parallel pursuing clarification on the spec and feedback from Mozilla engineer/architect people
15:52:35 <asn> (and there is also O2A5 to discuss)
15:52:43 <pospeselr> mcs: same
15:52:48 <asn> wow ok
15:52:48 <antonela> right
15:52:53 <sysrqb> antonela: i worry about implementing a feature that reduces security
15:52:56 <pili> asn: yup, thanks :)
15:53:01 <syverson_> If we're talking w/in the scope of S27, why would upliftability to FF be a problem since we're talking .onions?
15:53:01 <asn> sysrqb: yes
15:53:05 <asn> sysrqb: i also worry about doing so
15:53:07 <antonela> sysrqb: yes
15:53:18 <asn> i feel like doing security analysis 20 days before the end of the sponsor shows bad signs.
15:53:23 <dennis_jackson> I do not have a vote - but I am also worried about the security implications and the effort required
15:53:43 <asn> perhaps we can spend the remaining time analyzing the proposal and making it better and doing the necessary security analysis
15:54:00 <asn> i also dont want a vote fwiw. im not in the TB team.
15:54:11 <sysrqb> pospeselr: do you think alec would be interested in collaborating on this?
15:54:18 <sysrqb> maybe you and him could finish it?
15:54:21 <syverson_> asn: also use case mapping out since it's written assuming no DV certs.
15:54:22 <pospeselr> he seems ammenable
15:54:35 <asn> syverson_: right
15:54:36 <dennis_jackson> (I have no idea what the semantics of vote means in the context of tor, I just meant I don't have standing in any sense :) )
15:54:38 <pili> I think it's ok to not finish and have a clear path forward
15:54:51 <pili> it would be good to know whether the plan is to continue working on it after the project is over or whether we park it for a while
15:55:00 <sysrqb> syverson_: the uplift-potential is only important because we don't want to indefinitely carry these patches ourselves
15:55:14 <sysrqb> syverson_: so knowing if there is a possibility of uplift may influence our decision
15:55:39 <pospeselr> sysrqb: fortunately the implementation approach suggested by mozilla engineers will be an easy patch to carry forward
15:56:02 <pospeselr> assuming they don't go rearchitect certverfier.cpp which seems unlikely
15:56:03 <sysrqb> pospeselr: good
15:56:15 <sysrqb> yeah, i would worry about some weird overhaul of their code
15:56:16 <syverson_> sysrqb: sure but, for the simple solution it might not need carrying forward once replace by better (upliftable) alternatives.
15:56:19 <pospeselr> it's got that old code smell that doesn't want to change drastically
15:56:22 <sysrqb> pospeselr: and us being screwed
15:56:27 <pospeselr> mmhm
15:56:32 <sysrqb> ha, okay
15:56:46 <syverson_> I don't think there will be a problem dropping support for things, but what do I know.
15:56:47 <sysrqb> syverson_: yes, that's true
15:56:49 <mcs> someone is probably rewriting that code in Rust right now ;)
15:57:03 <sysrqb> mcs: also true :)
15:57:03 <pospeselr> mcs: well that probably isn't the worst idea I've heard
15:57:17 <sysrqb> (2 moinutes)
15:57:21 <sysrqb> *minutes
15:57:25 <antonela> we are close to the hour folks
15:57:31 <sysrqb> okay, pospeselr let's try this
15:57:32 <asn> and we didnt discuss o2a5
15:57:40 <sysrqb> ping alec and see if you can make progress on it
15:57:45 <asn> sysrqb: +1
15:57:46 <sysrqb> and see how far youget
15:57:51 <sysrqb> *you get
15:58:00 <antonela> and we hope you dont burn out in the process pospeselr
15:58:05 <sysrqb> haha
15:58:12 <sysrqb> +1
15:58:13 <pili> Ok
15:58:29 <pili> Let’s end this meeting them
15:58:33 <pili> Then
15:58:44 <pili> #endmeeting
15:59:00 <pili> Thanks everyone!
15:59:34 <antonela> #endmeeting
15:59:54 <antonela> the bot also left us
16:00:02 <asn> pili needs to do it
16:00:10 <antonela> she did it
16:00:15 <dennis_jackson> thanks pili! o/
16:00:16 <pili> Hmm
16:00:25 <asn> she had a whitespace
16:00:31 <sysrqb> pili: see pm
16:00:42 <pili> #endmeeting