[tor-bugs] #4570 [Tor Bridge]: Implement certificate serial number covert channel (part of proposal 179)

[Tor Bug Tracker & Wiki]

#4570: Implement certificate serial number covert channel (part of proposal 179)
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:       
     Type:  defect      |         Status:  new  
 Priority:  normal      |      Milestone:       
Component:  Tor Bridge  |        Version:       
 Keywords:              |         Parent:  #3972
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------

Comment(by nickm):

 Replying to [comment:4 asn]:
 > Replying to [comment:3 nickm]:
 > > Replying to [comment:2 asn]:
 > >
 > > > We will always have false positives with this scheme, till all the
 non-0.2.3.x relays disappear from the network.
 > >
 > > Unless we use the other v3-indicating cert features plus the SN to
 indicate
 > >
 > > Let's take a step back -- do you currently think this feature is a
 good idea?  I don't think it's workable if we have user-provided certs,
 and I think that getting user-provided certs to work is more important
 than this.
 > >
 >
 > I don't think it's a good idea.

 Then let's not do it, if neither one of us is advocating for it.  We don't
 need to reach agreement about why we don't want to do it in order not to
 do it. :)

 I'm going to mark this as wontimplement and close it.  After responding
 below, of course!

 >
 > I can see a use for it, but like you said, it kills the user-provided
 /CA-signed certs idea (which is *very* important). Less importantly, it
 provides a "at 75% this is a Tor relay" fingerprint to censors

 Probability error.

 Suppose there are 1e6 SSL sites, and 1e4 tor nodes.  (I'm deliberately
 skewing the estimates.)  Suppose that if you see a "special" SN, you can
 conclude that it might be a Tor node, but if you see a "non-special" SN,
 you can conlude that it is definitely not a Tor node.  Suppose that 25% of
 all other nodes have a special SN by accident.

 If you see a special SN, would you know with P=75% that it's a Tor node?

 Nope!  Bayes's Theorem gives P(tor|special) = P(special|tor) * P(tor) /
 P(special) = 1 * (1e4/[1e4+1e6]) /  ([1e4 + .25 * 1e6] / [1e4+1e6]) =
 about 3.8%.

 >, and it feels very hacky and last-hope to a problem we are not currently
 having

 "we are not having this problem currently" is not a great argument against
 future-proofing.

 >, since:
 > - v3 seems good.
 > - future 'in-protocol' link protocols can be negotiated by sending a
 v3-signaling SSL handshake and then negotiating v4 over VERSIONS.
 > - if we ever need to negotiate 'some other kind of TLS handshake' (for
 whatever reason) we can use signalling in the SSL handshake but outside of
 the Certificate. For example, we can use the SessionTicket field in the
 ServerHello (which relays currently send empty), or use another TLS
 extension (which are getting popular lately with ECC).

 This last one actually _is_ pretty persuasive.  So, as mentioned, closing.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4570#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online