Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Marsh Ray <[e-mail]>]

Nicolas Williams wrote:
> On Tue, Nov 10, 2009 at 01:37:27PM -0600, Steve Dispensa wrote:
>> This was discussed a bit at the Sept. 29 meeting. I had originally suggested
>> that the extension need not be present during initial negotiations at all,
>> but it was pointed out that network management systems might want to
>> inventory patched clients and servers.
> 
> I guess we'll see whether the need to interop with broken servers (which
> are probably broken forever, and therefore vulnerable forever) is
> important enough that implementors will have to include a knob for
> whether to send this extension on initial negotiations.  I consider the
> fact that it will break such broken servers a feature, but one must be
> realistic also.

It's one thing to say, realistically, some client applications may elect
to put their users at risk for the sake of continuing to work with
defective servers.

It's something else entirely to propose that an IETF spec's official
language and recommended practice for implementors should be weakened in
consideration for these noncompliant systems.

Perhaps those responsible for such systems will take this opportunity to
update them?

Yair Elharrar wrote:
> This could backfire. It would allow hackers to detect unpatched
> clients, and focus their attacks on them.

There are plenty of ways for to attackers to fingerprint clients (looked
at a user-agent string lately?) and it doesn't make sense to make life
difficult for those who have a legitimate need for the data.

Again, where there are trade-offs affecting security and
interoperability, let us favor the side of implementations that will
follow the specs and recommendations over those which do not.

- Marsh