[TLS] Third Option?

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

Return-Path: <ravi@findravi.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 79BD13A6A71 for <tls@core3.amsl.com>; Wed, 16 Dec 2009 14:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.976
X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id xwp+2JA98kCK for <tls@core3.amsl.com>; Wed, 16 Dec 2009 14:17:24 -0800 (PST)
Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com []) by core3.amsl.com (Postfix) with ESMTP id 1A17C3A6A5F for <tls@ietf.org>; Wed, 16 Dec 2009 14:17:23 -0800 (PST)
Received: by pwi20 with SMTP id 20so990413pwi.29 for <tls@ietf.org>; Wed, 16 Dec 2009 14:17:06 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id 25mr1083119wab.103.1261001826080; Wed, 16 Dec 2009 14:17:06 -0800 (PST)
Date: Wed, 16 Dec 2009 14:17:06 -0800
Message-ID: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="00504502f52be79887047adfdd2e"
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 22:17:25 -0000

> >>>>  As a protocol climbs the IETF standards-track maturity ladder, we
> >>>>  sometimes drop features.  I would rather see renegotiation dropped
> >>>>  from TLS than see this complexity added to TLS protocol.
> >>>
> And, as Marsh has said on other threads, to remove a widely used feature is
> tantamount to forking the protocol.
>  -Steve
A third option is to leave renegotiation in, but create an advisory that
explains the semantics; namely, it is indeed a RE negotiation, and SSL/TLS
itself is starting from scratch and not making any assumptions about what
went before and what came after. A higher layer protocol that chooses to mix
and match traffic is making assumptions about guarantees from the SSL/TLS
layer that are certainly not "explicitly" being made anywhere.

This is not because I think renegotiation should continue to work the way it
should; in fact I believe the attack discovered was valuable, and changes
discussed on this thread over the last several weeks are valuable and SHOULD
be added in --- just that they should be added in to TLS 1.3 and the
upgrades should happen in the natural order of things. Those immediately
impacted (especially those doing the no-client-auth renego client-auth
sequence) should fix at app layer.

I am just applying my own gut sense of Occam's Razor on  the
"harm caused by not fixing until TLS 1.3"
"harm caused by forcing lots and lots of clients and servers that do not
need it"
into a significant change. As someone who wore an "operations pager" for too
many years, I do not believe in "insignificant" changes. If a developer as
much as LOOKS at a disk containing operational code, they will find a way to
break it which will not be discovered until much later....

Finally, regardless of where the committee ends up, I believe the
recommendation's value in the eyes of those who have to make decisions on
"to patch now or to wait until I need to upgrade anyway" if it contains
advice on this topic. Anyone reading about this attack from the media will
have absolutely no clue as to impact.

Anyone who reads the  the first documents that came out on this issue (
http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and
would be left with very different perceptions of the magnitude of the
impact. This is not unnatural in such matters; great minds usually think
differently...., but after all this discussion perhaps a blurb in the draft
with advice on who should immediately patch might be useful.

Ravi, www.findravi.com