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

[David-Sarah Hopwood <[e-mail]>]

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.

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

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com