Re: [TLS] Third Option?

Martin Rex <mrex@sap.com> Thu, 17 December 2009 16:02 UTC

Return-Path: <mrex@sap.com>
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 B1A6A3A68B4 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 08:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level:
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 TPpHEamr9ZFF for <tls@core3.amsl.com>; Thu, 17 Dec 2009 08:02:04 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 9E0023A63EB for <tls@ietf.org>; Thu, 17 Dec 2009 08:02:04 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHG1fSp007785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 17:01:41 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912171601.nBHG1ef5027443@fs4113.wdf.sap.corp>
To: ynir@checkpoint.com
Date: Thu, 17 Dec 2009 17:01:40 +0100
In-Reply-To: <A7CF2975-9462-44CD-80E5-88E5AC4071C2@checkpoint.com> from "Yoav Nir" at Dec 17, 9 08:58:15 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: ravi@findravi.com, tls@ietf.org
Subject: Re: [TLS] Third Option?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 17 Dec 2009 16:02:05 -0000

Yoav Nir wrote:
> 
> What do you (as a vendor) tell your customers when they know they are
> vulnerable and call you for a fix?
> 
> Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers
> to move to newer release in order to fix security problems is something
> the market understands. (did not say 'likes').

I haven't seen a market that understand this.
Vendors have been shipping very annoying auto-update functionality
in order to get at least a part of the installed base to upgrade.

Outside of the commodity market, you may get to see some customer's
lawyers if you suggest "moving to a newer release" instead of providing
a patch to defects in your products.


> - There's no signaling that renegotiations are disabled.
>   The browser cannot show me that I'm talking to a secured server.

Yes, I feel so much safer when I know that I'm talking to an TLS-updated
rogue server.  The difference this update will make is much smaller
as some try to make you believe.  It is definitely not like you
are competely and hopelessly insecure without it, and
top-notch invincible as soon as you deploy it.

The endpoint identifications used by application protocols on top of
TLS contains plenty of weaknesses itself.  So it's not like you
should stop worrying.  It's just that your focus shifts and you
have to worry more about other things now, some of which may me
much harder to fix.


-Martin