Re: [TLS] Quest for Unified Solution to TLS Renegotiation

[Michael D'Errico <[e-mail]>]

Eric Rescorla wrote:
> Michael D'Errico wrote:
>> I think that it would be good to find a unified solution that
>> everybody is happy with, and believe that this may be it:
> 
> This was actually suggested by Bodo Moeller last week.

Yes, I just reread his message of Nov. 15 which states:

      One way to avoid most of the overhead from the current
      ID would be to keep the extension *always* empty.  If
      the client and server both send it during any given
      handshake, then the Finished messages concluding that
      handshake will be computed mostly in the standard way,
      but if it's a renegotiation handshake, including the
      previous handshake's Finished messages in the handshake_
      messages that will be hashed.  [Open question: Where
      should they go?  Maybe the easiest is to always hash
      them at the end; client first, server second.]

>>    1) Client-to-Server signalling can be done in either of
>>       two ways:
>>
>>       A) an empty Secure_Renegotiation (SR) extension, or
>>       B) a "magic" cipher suite
>>
>>    2) Server-to-Client signal is always an empty SR extension
> 
> I just sent a message suggesting 1 and almost 2.

Great, we are getting closer.

>>    3) Incorporate previous verify_data into Finished calc.
> 
> I'm not happy with this, actually.
> 
> 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 think that moving forward to TLS 1.3 and beyond, we really want
the old verify_data incorporated directly into Finished, don't we?
Using an extension for this only makes sense because we need to
patch old versions.

The complaint I have about sending the verify_data over the wire is
that that alone does not plug the hole.  You need to take the extra
step to check that it's correct, and a maintenance programmer not
intimately familiar with TLS might miss this fact.

Changing Finished to the way we would like it in TLS 1.3 and beyond
seems like a better way to proceed.  Chaining the previous handshake
messages with the renegotiation does seem like a cleaner approach
than inserting the old verify_data into the handshake stream, so I'd
support that if that's the consensus.

Mike