Re: [TLS] draft-ietf-tls-renegotation: next

[David-Sarah Hopwood <[e-mail]>]

Kyle Hamilton wrote:
> Also, it is illegal for any TLS implementation to negotiate
> NULL-NULL-NULL, and it is illegal for any TLS implementation to
> transmit application data after the initial handshake has been
> initiated and before the Finished messages have been generated by both
> sides.
> 
> This would suggest that another mitigation for this attack would be to
> include a zero-length application-data packet in all renegotiations;
> if one side thinks it's an initial negotiation, and it receives an
> application data packet under the state that it thinks is
> NULL-NULL-NULL, it is required that it close the connection with a
> fatal handshake_failure alert.
> 
> (The only problem with this potential mitigation is that if the client
> is connected to the MITM, and the MITM is connected to the server, the
> MITM could simply strip out the zero-length application-data chunk,
> since TLS relies on underlying mechanisms to verify that it has a
> two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a
> clean serial line, or an MNP5 modem.  TLS doesn't try to detect lost
> chunks from the server.)

Unfortunately, this problem is a fatal objection to what was otherwise
a very interesting idea:

 - If the extra record is sent before the ChangeCipherSpec of a
   renegotiating handshake, then the attacker can strip it out
   (because it won't be included in the handshake_messages,
   and it doesn't affect the sequence number of messages after the
   ChangeCipherSpec, which resets the sequence number to zero).

 - If the extra record is sent after the ChangeCipherSpec but
   before the Finished message, then (by my reading) the receiving
   peer MUST treat this as a fatal error regardless of whether it
   believed the handshake was initial or renegotiating.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com