[TLS] Third Option?

Ravi Ganesan <ravi@findravi.com> Wed, 16 December 2009 23:36 UTC

Return-Path: <ravi@findravi.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 0B5003A6AA5 for <tls@core3.amsl.com>; Wed, 16 Dec 2009 15:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 bytrTpHrgrYf for <tls@core3.amsl.com>; Wed, 16 Dec 2009 15:36:51 -0800 (PST)
Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 4265B3A67AF for <tls@ietf.org>; Wed, 16 Dec 2009 15:36:51 -0800 (PST)
Received: by pwi20 with SMTP id 20so1032410pwi.29 for <tls@ietf.org>; Wed, 16 Dec 2009 15:36:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.115.132.12 with SMTP id j12mr1136391wan.121.1261006594336; Wed, 16 Dec 2009 15:36:34 -0800 (PST)
In-Reply-To: <3561bdcc0912161509j799392d1t2f4f09a7d1184737@mail.gmail.com>
References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <3561bdcc0912161509j799392d1t2f4f09a7d1184737@mail.gmail.com>
Date: Wed, 16 Dec 2009 15:36:34 -0800
Message-ID: <3561bdcc0912161536y5e240e6cqe414c7d4aa2baef8@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0016e648f4b21d6704047ae0fa90"
Subject: [TLS] Third Option?
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: Wed, 16 Dec 2009 23:36:52 -0000

On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray <marsh@extendedsubset.com> wrote:

> Ravi Ganesan wrote:
> >
> > A third option is to leave renegotiation in, but create an advisory that
> > explains the semantics;
>
> 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').

However, if you are correct in your impact analysis in your original paper,
then an emergency patch is the appropriate response. I am not sure I know
enough to agree with your impact analysis, but either way, good job done by
your team and Martin on this discovery -- it will make TLS 1.3 better.

One stat that might allow us  to ascertain immediate impact: If I am a web
site who strictly ONLY uses server side SSL (with client auth being handled
by passwords, etc.),  And, I have ability to turn of renego. Will that do
the trick? If so what portion of SSL users fall into this use-case?



-- 
Ravi Ganesan
ravi@findravi.com
www.findravi.com