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

[Dr Stephen Henson <[e-mail]>]

Marsh Ray wrote:
> Dr Stephen Henson wrote:
>> Eric Rescorla wrote:
>>> I'll also make whatever small editorial changes I see. If I've
>>> missed something important that people think there is consensus on,
>>> please let me know. There are a lot of messages, so I may well
>>> have.
>>>
>> In 6.1:
>>
>> If clients wish to ensure that such attacks are impossible, they MUST
>>  terminate the connection immediately upon failure to receive the 
>> extension without completing the handshake.
>>
>> Should we be more specific about what "terminate the connection"
>> means? Does that mean drop the connection immediately without sending
>> anything else or by sending a fatal alert?
> 
> The spec says "Upon transmission or receipt of a fatal alert message,
> both parties immediately close the connection."
> 
>> If a fatal alert which one? Presumably handshake_failure?
> 
> How about 'unexpected_message'? That's what I see when mixing
> application data into a renegotiation handshake that wasn't expecting it.
> 

Just to be clear here: I'm not referring to an attack but where we have a strict
patched client that refuses to connect to an unpatched server. That is client
makes initial handshake using RI+MCSV, doesn't get RI back and decides this is
not acceptable.

This is a scenario which is quite likely to happen at some point. Well it
happens already in my test environment ;-)

I'm asking whether a client should send a fatal alert here so a server admin can
get some hint of the cause or if it should just silently drop the connection.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.