Re: [tor-bugs] #5563 [Tor Relay]: Better support for ephemeral relay identity keys

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5563: Better support for ephemeral relay identity keys
-------------------------+--------------------------------------------------
 Reporter:  mikeperry    |          Owner:       
     Type:  enhancement  |         Status:  new  
 Priority:  normal       |      Milestone:       
Component:  Tor Relay    |        Version:       
 Keywords:               |         Parent:  #5456
   Points:               |   Actualpoints:       
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:4 arma]:
 > Replying to [comment:3 mikeperry]:
 > > arma: I don't think so. I think I'm actually most concerned about our
 TLS keys, which I believe are rotated daily.
 >
 > Every 2 hours:
 > {{{
 >   /** 1b. Every MAX_SSL_KEY_LIFETIME_INTERNAL seconds, we change our
 >    * TLS context. */
 > }}}

 Ah, tor-spec.txt says "should".. "at least once a day".

 > >But this rotation doesn't help if you assume an active adversary
 operating upstream from you. Can't they just take whatever keys you create
 and toss them away and re-sign new ones they control, using the identity
 key?
 >
 > Yes. But then when you send them a CREATE cell they won't be able to
 decrypt it unless they know your onion key too. So the attack they need to
 do is publish a new descriptor in your name, signed by your identity key,
 listing their own onion key -- and then also be able to "be" you from the
 perspective of the network. If the attacker can do all that, how will
 shorter identity key lifetimes help?

 Well first off, I'm pretty sure that the onion key is irrelevant to
 tagging-based amplification. An attacker interested in tagging-based
 amplification need only unwrap the TLS link key, which is authenticated
 only by the identity key (according to my read of tor-spec). Once the
 adversary has have the ability to see inside TLS, they can read the
 command field of cell payloads. The adversary then happily lets the
 original onionskin negotiation in CREATE complete, which negotiates a
 symmetric key unknown to the adversary. This doesn't matter, because AES
 CTR allows them to then embed an arbitrary tag in the following RELAY cell
 which sets up the stream. Nodes unable to undo the tag in the RELAY cell
 fail the circuit, which provides the amplification.

 Also, if I've missed something and the onion key *is* needed, what
 actually verifies that the onion key you try to publish is what gets
 published?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5563#comment:5>
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