Re: [tor-bugs] #5968 [Tor]: Improve onion key and TLS management

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5968: Improve onion key and TLS management
-------------------------+--------------------------------------------------
 Reporter:  mikeperry    |          Owner:                    
     Type:  enhancement  |         Status:  new               
 Priority:  major        |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor          |        Version:                    
 Keywords:  tor-relay    |         Parent:  #5456             
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:7 nickm]:
 > If the attacker can steal the identity key for a server, they could
 publish their own descriptors to the authorities, containing their own TLS
 cert hash and IP.  The server operator might notice, but the users
 wouldn't.

 What I want to remove is the ability for someone demand a guard's identity
 key and target specific users using interception hardware operating
 independently from that relay. The reason I want to prevent this specific
 case is because it's an adversary that can make money subverting Tor's
 security through the sale of such devices, which means the arms race
 escalates faster. Such adversaries will be incentivized to subvert/weaken
 legal systems to support their existence.. We should be sure to head them
 off before they begin to exist for this usecase, I think.

 If TLS certs are also validated through the consensus somehow, we could
 prevent such devices from being possible without persistent compromise,
 which I do think is a different beast. See below.

 > Sticking this int the _micro_descriptors seems pretty heavyweight.
 Maybe I don't understand the attack, though.  If the attacker can steal
 the identity key for a server, it seems to me that they could also steal
 the onion key, replace the server's Tor software, trojan the server in
 some other way, publish descriptors with a different onion key, and so on.
 I don't think that "identity key compromise" is something that a server
 can really recover from in our design.

 In the future, secure boot and/or a readonly runtime could authenticate
 tor relays from many classes of such adversaries except one: some guy with
 a gun who demands you hand over your key.

 With a frequent enough TLS key rotation, we can make such requests
 impractical, or at least bounded by what minimal restrictions on such
 repeated requests may be in place.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5968#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs