[tor-bugs] #5488 [Analysis]: Write Internet drafts for one or two TLS features to improve its traffic-analysis resistance

[Tor Bug Tracker & Wiki]

#5488: Write Internet drafts for one or two TLS features to improve its traffic-
analysis resistance
----------------------+-----------------------------------------------------
 Reporter:  karsten   |          Owner:  nickm                      
     Type:  project   |         Status:  new                        
 Priority:  normal    |      Milestone:  Sponsor F: November 1, 2012
Component:  Analysis  |        Version:                             
 Keywords:            |         Parent:                             
   Points:            |   Actualpoints:                             
----------------------+-----------------------------------------------------

Comment(by asn):

 It seems that Marsh not only wrote a draft for his idea, but the draft was
 also quite well received by the TLS community:
 https://www.ietf.org/mail-archive/web/tls/current/msg08722.html

 He proposes two schemes:
 One scheme, where the ClientHello is transferred in plaintext, the rest of
 the discussion is encrypted, and the number of round trips is the same as
 in classic TLS.
 And another scheme, where a ''dummy'' ClientHello is initially
 transferred, all the discussion is encrypted (including the ''actual''
 ClientHello that carries extensions etc.), but the number of round trips
 is increased by one.

 If this proposal gets accepted and implemented, the browser/httpd vendors
 will decide which of the two schemes to use, and this will decide which
 scheme we will have to use.

 In the last section, there is:
 {{{
    o  It cannot be repeated often enough that the early encryption
       negotiated by the EH extension *only* provides protection from
       passive eavesdropper.  It *can not* resist a man-in-the-middle
       type active attacker who wishes to steal a sample of the plaintext
       the client and server intended to exchange (doing so will break
       the handshake however). Like TLS without EH, full protection from
       an active attacker only begins after the Finished messages are
       received and validated by each side.
 }}}

 since the proposal does not protect against MITM or active-probing-like
 attacks.

 I wonder if there is anything smart that can be done to add protection
 against MITM.

 For example, adding a post-Finished phase where parties could exchange
 metadata would help against MITMs, but it would also add another round
 trip. Furthermore, if such a phase was client-initiated and optional, we
 would be able to use it only if everyone else did so too, otherwise we
 would stand out against a passive adversary (lame plaintext TLS record
 headers).

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