Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

[Yoav Nir <[e-mail]>]

On Dec 15, 2009, at 11:26 PM, David-Sarah Hopwood wrote:

> Yoav Nir wrote:
>> On Dec 15, 2009, at 4:46 AM, David-Sarah Hopwood wrote:
>> 
>>> Yoav Nir wrote:
>>>> It would be easy to require this, but it's not compliant with the current
>>>> spec. The current spec says that the finished value depends on all the
>>>> bytes starting with the first byte of the ClientHello.
>>>> 
>>>> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but
>>>> adding the previous finished message is a change to the spec, one that
>>>> requires some sort of signaling, either with a fake cipher suite or with
>>>> an extension.
>>> 
>>> No, this is a misunderstanding; changing how the Finished message is
>>> computed *for renegotiations* does not necessarily require signalling.
>>> 
>>> Changing the way that the Finished message is computed *only* for
>>> renegotiations, would affect interoperability only when there is a
>>> renegotiation where one peer is unpatched and the other is patched.
>>> Under that condition, being interoperable would allow an attack.
>> 
>> That is just wrong.
> 
> You're mistaken. What I said is precisely correct.

I did not mean "wrong" in the sense of incorrect, but "wrong" in the sense of something we shouldn't do.

> 
>> An RFC compliant client negotiating with an RFC compliant
>> server must not get a wrong Finished message.
> 
> That is not a requirement. It does not matter whether a handshake
> failure is due to a mismatch in the Finished messages, or a client or
> server explicitly aborting because it required that renegotiation is
> only performed with a patched peer.

Of course it is. Finished message should never fail to verify, unless there is a real attack going on. They are there to detect attacks, not to detect unpatched peers.

Detection of unpatched peers or the requirement to patch should be through signaling or alerts.