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

[Eric Rescorla <[e-mail]>]

At Fri, 27 Nov 2009 16:00:38 +0100,
Stefan Santesson wrote:
> Many members of this list argue that 2a has better security properties and
> is simpler to deploy (especially for legacy implementations).
> The arguments for 2b seems to be that it is "good enough" and "why should we
> care about old legacy implementations".

I don't think this characterizes my position particularly well:

- I don't think that having the data not carried in the message obviously
  has better security properties. There may be some version that clearly
  does, but I haven't seen it yet. My suspicion is that the "best" versions
  of each of these approaches have equivalent security, but as I said
  in a previous message, I'm concerned about the specific "implicit"
  versions I've seen proposed.
  
  [For the record: your argument about reducing information leakage
  is, AFAICT, incorrect. The verify_data in the Finished is carried
  over the same encrypted channel as the new handshake messages. Any
  attacker who can see the second can see the first.]


- I don't agree that it's simpler to deploy versions that don't carry the
  verify_data in an extension. It may require fewer lines of code
  (though honestly, the number of lines we're talking about here
  is so few, it hardly matters), but on the other hand, the lines
  of code are in core pieces of TLS, not in peripheral pieces.


- I'm not sure where you get the idea that carrying the verify_data
  in an extension somehow involves not caring about legacy implementations.
  Perhaps you and I have different views of what that would involve.
  As I observed earlier, TLS connections that use RI (and not the magic
  cipher suite) are fully compliant with all existing TLS RFCs.
  That seems pretty legacy-friendly to me.


In short, I don't think that signaling the previous verify_data in the 
extension is merely "good enough". I think it's better.

-Ekr