Re: [TLS] TLS renegotiation issue
Martin Rex <mrex@sap.com> Fri, 06 November 2009 01:05 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 DD42628C10D for <tls@core3.amsl.com>; Thu, 5 Nov 2009 17:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.749
X-Spam-Level:
X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, 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 2C05PMmdEw8t for <tls@core3.amsl.com>; Thu, 5 Nov 2009 17:05:29 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6F1D83A6A06 for <tls@ietf.org>; Thu, 5 Nov 2009 17:05:29 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA615kHH027450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 02:05:46 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911060105.nA615jen027166@fs4113.wdf.sap.corp>
To: mickgray@au1.ibm.com
Date: Fri, 06 Nov 2009 02:05:45 +0100
In-Reply-To: <OF932FC8F5.DD33A5E8-ON4A257665.00777725-4A257666.00000910@au1.ibm.com> from "Michael Gray" at Nov 6, 9 10:00:23 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
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: Fri, 06 Nov 2009 01:05:31 -0000
Michael Gray wrote: > > Eric Rescorla <ekr@rtfm.com> wrote: > > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html > > IMHO The proposed fix looks to be also introducing the concept of > Retrospective Trust into TLS. This being necessary due to the problem > highlighted in the HTTP protocol in that it will process messages that > arrived prior to authentication etc. To some degree I share your concern. However, I do believe that the the proposed fix to provide secure renegotiation primarily fixes a problem in the TLS protocol, which does not live up to its own promises on security of a TLS session renegotiation. Admittedly, the momentum behind this effort is the prospective blessing this will provide on the current awful practice in this area, because first of all, vendors _and_ implementors are trying to maintain the current level of look&feel / usability -- or maybe we should call it "convenience". If we forgive the applications today, they are going to do even more daring things tomorrow -- and that could be things that we cannot fix easily. In real life, however, security is much more about risk management than absolute security. Bruce Schneier has written at least a dozen good articles about that topic. The more difficult security is to use, the more often people will work around it. I think we should improve on guidance, rather than be totally anal about who goofed which part. > > However, IMHO I would guess that once TLS is perhaps protected, > then the attacker will simply attack at some other level as the > HTTP/Web Application is still vulnerable. IMHO these other > attacks might be easier to do and perhaps at the same time harder to > detect. Just a second! The problem were addressing here is _NOT_ easily detectable. I think it is just the opposite. There has always been an arms race. And I don't see how or why this would change in the future. What exactly do _you_ suggest? That we _not_ fix this issue in TLS, so that the apps can keep pointing on us and do not have to fix their other problems? Is that really going to help? > My view is that implying Retrospective Trust in TLS will lure > application developers into incorrectly thinking they are now (or are > still) safe and continue the IMHO dangerous practice of Retrospective > Trust. IMHO I would question why allowing the concept of Retrospective > Trust into TLS is not inherently dangerous. As inidicated at the beginning, there is some truth in what you're saying. But looking at all aspects of the problem, I don't feel like not fixing this is the bigger evil. But your criticism about the Retrospective Trust is quite valid. It is a dangerous design, and it is questionable that the risk it brings is worth the convenience it offers. Compare it to this real-world scenario: Today, many companies have tight control on who enters their office buildings, and it helps them to manage their risk and gives them some amount of audit and accountability. The Retrospective Trust means that you get rid of that control at the building entrance. Instead, you solely rely on your own perfection to reliably check each and everyone that leaves an office with a binder in his hands. Either he must show his permission or leave without the binder. You regularly find someone without permission, but you're not allowed to ask his name, and a few of them constantly do this and you have no means to keep them out of your building. I would not describe the latter as sensible risk management. It doesn't look very reliable or robust. But if you implement some convenient "permissions check" (hey, rfid is fun, isn't it), it might feel quite convenient for the people that work there. Having to pass a gate one-by-one during rush hour (morning,lunch,evening) often creates a less appealing user experience. -Martin
- [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- [TLS] TLS or HTTP issue? (was: TLS renegotiation … Nikos Mavrogiannopoulos
- Re: [TLS] TLS renegotiation issue Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Cullen Jennings
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael Gray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] TLS or HTTP issue? Bruno Harbulot
- Re: [TLS] TLS renegotiation issue Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] TLS or HTTP issue? Peter Saint-Andre
- Re: [TLS] TLS or HTTP issue? Martin Rex
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nathaniel W Filardo
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Robert Relyea
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] TLS or HTTP issue? Dean Anderson
- Re: [TLS] TLS renegotiation issue David Harrington
- [TLS] To API or not (Re: TLS renegotiation issue) Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Marsh Ray
- [TLS] Simple way to drop re-negotiation in HTTP (… Nicolas Williams
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] Simple way to drop re-negotiation in HT… Marsh Ray
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS or HTTP issue? Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] TLS renegotiation issue Nagendra Modadugu
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS or HTTP issue? Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] Simple way to drop re-negotiation in HT… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Chris Newman
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Chris Newman
- Re: [TLS] TLS renegotiation issue Bodo Moeller
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- [TLS] Comments on draft-rescorla-tls-renegotiate Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nelson B Bolyard
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Bodo Moeller