Re: [TLS] Verify data in the RI extension?

[Eric Rescorla <[e-mail]>]

At Fri, 27 Nov 2009 09:54:41 +0100,
Stefan Santesson wrote:
> 
> The current draft-ietf-tls-renegotiation-01.txt still promotes RI extension
> containing verify_data from previous handshake.
> 
> Sorry for repeating my question, but I would be really interested to know
> why this is considered a better security design, than to simply send an
> empty RI (and to feed the values directly into Finished calculation without
> exchange).

I think I answered this question with my view in an earlier message:

  This requires breaking the current clean definition of handshake
  hashes as the hash of all the handshake messages and simply adding
  some synthetic message in the middle. I don't think this is anywhere
  near as clean, as evidenced by the ongoing debate about whether to put
  it the synthetic data in the front, the back, incorporate it into the
  PRF, or chain the pre-existing handshake messages. [FWIW, I think I
  prefer the last of these implicit versions.]
  
  By contrast, RI allows that part of the system (which is well
  understood) to remain the same and in fact when RI is offered on the
  first handshake, there is no change to the TLS core at all. It's all
  just hashed into Finished as part of the ordinary TLS procedures,
  and everything is in fact compliant TLS, which I think is desirable.
  
  I appreciate that this is to some extent a matter of tradeoffs,
  but I don't find the arguments in favor of the implicit version
  very compelling when weighed against the above.

I also share David Hopwood's concern about ambiguity in the handshake
hashes stream created by having data which is not properly formatted
injected into the hash
(http://www.ietf.org/mail-archive/web/tls/current/msg04857.html),
so I don't think the particular approach in Martin's draft is
really satisfactory.

This isn't to say that one couldn't design a mechanism that didn't
carry the signaling data over the wire--one obviously could. 
However, when I look back over the 50 or so messages that were
sent to the list yesterday, a large fraction of them are various
tweaks on exactly how incorporate that data, which suggests to
me that this approach isn't at all easy to reason about.

-Ekr