Subject: Re: [TLS] Server-only solution - proposed text

From: Yaron Sheffer <[email-masked]>
Date: Thu, 26 Nov 2009 19:55:09 +0200

Hi,

I proposed this text earlier this week. It did not make its way into draft -01, and I think it's important enough to reiterate. We should allow server administrators some freedom in setting their own policy, "just saying no" is not a good option.

Thanks,
            Yaron

________________________________
From: Yaron Sheffer
Sent: Monday, November 23, 2009 11:24
To: [email-masked]'
Subject: Server-only solution - proposed text

Hi,

Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I-D-to-be) are making changes to the protocol, and therefore will only become effective once a good percentage of clients have been patched. In the meantime, administrators could fix their (patched) servers locally in many cases, without waiting for the client population to get fixed. I propose to add the following short section to both drafts:

X. Server-Side Mitigation Procedures

We assume that it will take a significant amount of time until the protocol change defined in this document is adopted by all clients. However, in many cases a server-only mitigation is possible in the interim: many TLS applications, and in particular, many Web (HTTPS) applications, do not require renegotiation for proper operation. Implementations of the current document (unless they employ a strict policy, allowing only protected clients to connect) SHOULD be configurable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

-       Allow any renegotiation with unprotected clients.
-       Allow only server-initiated renegotiation with unprotected clients.
-       Disallow renegotiation with unprotected clients..

The default setting is a matter of vendor and/or local policy.

[Note: this contradicts the sentence "Servers SHOULD NOT allow clients to renegotiate without using this extension" in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be followed by many implementers.]

Thanks,
            Yaron