[TLS] Verify data in the RI extension?

[Stefan Santesson <[e-mail]>]

Eric and all,

On 09-11-25 11:35 PM, "Eric Rescorla" <[e-mail]> wrote:

> What about not putting the verify data in the extension?
> I think that issue is separable from the question of how we signal
> support, so would like to deal with it separately.

I would like to elaborate my support for an RI with absent verify data.

The major argument I have seen for including verify data in the RI extension
is that it would allow us to preserve the current Finished calculation. This
will allow us to use more of the current implementation code and provide a
more clean design.

I think these to a major extent are valid arguments, but I find the opposing
arguments even more convincing. These are:


1) Empty RI It's good security design

If you want to make sure two parties agree on a value that they have derived
from a previous state, in order to bind to the previous state, then why
would you exchange that value before doing the check?

On the contrary, I find it to be good security design not to exchange that
value as it:

1) Reduce information leakage to an attacker
2) Increase the security assumptions that can be made based on a proof of
matching values (good Finished messages).

Even if there are no attack today to exploit the information leakage and
exchanging the values allows secure design, I still find it valuable to
apply the best possible security design to reduce the chance of future
problems. 


2) Better migration path towards future

If we would design TLS 1.3, then would we send this data in the handshake,
or would we not?

I suspect we would not, due to argument 1)
Exchanging this value serves no purpose other than saving a few lines of
code changes from TLS 1.2.

Consequently, if we design an updated Finished calculation now, we can keep
that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS
1.2.


3) Less likely to cause implementation problems

This is just my guessing based on what I have heard.
But if the client verify data is provided in RI, then it is not enough to
recognize the extension. It is now also necessary to parse it, extract the
data and to use it in a critical security check.

I can't really judge how likely this is to cause more implementation
problems or even implementations that appears to do the security check
against previous handshakes, but actually just feeds it into the finished
calculation blindly.

But it feels like good design to eliminate/reduce this type of problems if
possible. Especially if it is better security design at reasonable cost.

/Stefan