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

[Stefan Santesson <[e-mail]>]

Eric,

Thanks for the straightforward reply.
In-line;


On 09-11-27 4:22 PM, "Eric Rescorla" <[e-mail]> wrote:

> 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.
>   

I have a hard time believing that it would be a hard to define a structure
for inclusion of past verify_data that would work for implicit inclusion.

The real security advantage of implicit is that you know that the opponent
actually derived the same value from previous handshake. By sending it in RI
you don't know if the opponent just blindly accepted what you sent without
checking it. 

I think that is a significant security advantage for the implicit approach.


>   [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.]
> 

We can disregard that comment for this discussion. For this I agree with
you.

> 
> - 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.
> 


An RI from the client containing verify_data need to be parsed and values
have to be extracted by the server. This means requirement to add extension
handling at the server side for all versions of SSLv3 -> TLS 1.2.

In the alternative solution no server need to be bothered with parsing
extensions. Some people mean that this is much easier to implement for
legacy implementations. I just find their arguments convincing.


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

Fair enough.
I'm afraid I still disagree.

/Stefan


> -Ekr