[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.160.50]) 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 10.114.2.25 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" versus "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 http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html) 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
- [TLS] Third Option? Ravi Ganesan
- Re: [TLS] Third Option? Marsh Ray
- [TLS] Third Option? Ravi Ganesan
- Re: [TLS] Third Option? David-Sarah Hopwood
- Re: [TLS] Third Option? Marsh Ray
- Re: [TLS] Third Option? Yoav Nir
- Re: [TLS] Third Option? Martin Rex
- Re: [TLS] Third Option? Stefan Santesson
- Re: [TLS] Third Option? Kyle Hamilton
- Re: [TLS] Third Option? David-Sarah Hopwood