Re: [TLS] draft-ietf-tls-renegotation: next steps

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

Eric Rescorla wrote:
> At Wed, 16 Dec 2009 10:53:37 +0100,
> <[e-mail]> wrote:
>> - The current draft doesn't clearly say what should be included in
>> legacy (insecure) renegotiation ClientHellos. I am not sure if we have
>> enough clear opinions to call consensus, but keeping it aligned with
>> the initial ClientHello (either MSCV or extension) seems to be one
>> simple approach (but I hope to see the actual text).
> 
> Attached is some candidate text that attempts to implement this. 
> 
>   It is possible that un-upgraded servers will request that the client
>   renegotiate.  It is RECOMMENDED that clients refuse this
>   renegotiation request.  Clients which do so MUST respond to such
>   requests with a "no_renegotiation" alert [RFC 5246 requires this
>   alert to be at the "warning" level.] It is possible that the
>   apparently un-upgraded server is in fact an attacker who is then
>   allowing the client to renegotiate with a different, legitimate,
>   upgraded server.  In order to detect this attack, clients which
>   choose to renegotiate MUST provide either the
>   TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their
>   ClientHello.  In a legitimate renegotiation with an un-upgraded
>   server, either of these signals will be ignored by the server.
>   However, if the server (incorrectly) fails to ignore extensions,
>   sending the "renegotiation_info" extension may cause a handshake
>   failure.  Thus, it is permitted, though NOT RECOMMENDED, for the
>   client to simply send the SCSV. This is the only situation in which
>   clients are permitted to not send the "renegotiation_info" extension
>   in a ClientHello which is used for renegotiation.
> 
>   Note that in the case of this downgrade attack attack above, if this
>   is the initial handshake from the server's perspective, then use of
>   the SCSV from the client precludes detection of this attack by the
>   server.

That is not correct. If the server is also upgraded, it can detect that
the SCSV has been sent without the extension on a renegotiating handshake.
This case must be an attack, because the client wouldn't have sent only
the SCSV if it knew that the server was upgraded. (If the connection is
a legitimate renegotiation and the server hasn't changed, the client
would know that it is upgraded from the presence of the extension in
the ServerHello of the previous handshake.)

It is only un-upgraded servers that will not detect the attack (but
the client accepted that possibility, contrary to the RECOMMENDATION
in the second sentence of the above text).

OTOH, I think it's perfectly reasonable not to allow clients to send
only the SCSV on a renegotiation. As you say,

> Sending RI in this instance only creates
> an interop problem when a server (1) is doing something we know to be
> really unsafe and (2) can't even ignore extensions correctly.

Either way, the draft should specify that an upgraded server MUST abort
a renegotiating handshake if it receives only SCSV without the extension.

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