IETF Logo Mail Archive

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

"Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu> Tue, 10 November 2009 21:30 UTC

Return-Path: <uri@ll.mit.edu>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3544C3A6A2A for <tls@core3.amsl.com>; Tue, 10 Nov 2009 13:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level:
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+oiInfJEpKP for <tls@core3.amsl.com>; Tue, 10 Nov 2009 13:30:42 -0800 (PST)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9716C3A682D for <tls@ietf.org>; Tue, 10 Nov 2009 13:30:42 -0800 (PST)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAALV4fh000928; Tue, 10 Nov 2009 16:31:04 -0500 (EST)
Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAafa4zJ; Tue Nov 10 16:20:02 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Tue, 10 Nov 2009 16:20:02 -0500
From: "Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu>
To: "'marsh@extendedsubset.com'" <marsh@extendedsubset.com>
Date: Tue, 10 Nov 2009 16:19:23 -0500
Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities
Thread-Index: AcpiSysjhGpjvZMuQTGXaeJ6uZw4BgAAGTtG
Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3CD@LLE2K7-BE01.mitll.ad.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 21:30:44 -0000

Marsh,

Cannot agree more. 

(In fact I'm surprised that it had to be stated! :-)


----- Original Message -----
From: tls-bounces@ietf.org <tls-bounces@ietf.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Cc: tls@ietf.org <tls@ietf.org>
Sent: Tue Nov 10 16:17:28 2009
Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email