Re: [TLS] Summarizing identity change discussion so far
Marsh Ray <marsh@extendedsubset.com> Tue, 08 December 2009 23:27 UTC
Return-Path: <marsh@extendedsubset.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 A8F5C3A6915 for <tls@core3.amsl.com>; Tue, 8 Dec 2009 15:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
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 7dFpH7n8HUSX for <tls@core3.amsl.com>; Tue, 8 Dec 2009 15:27:06 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 87FFA3A683D for <tls@ietf.org>; Tue, 8 Dec 2009 15:27:06 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NI9SJ-000BVQ-AI; Tue, 08 Dec 2009 23:26:55 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 783C8603A; Tue, 8 Dec 2009 23:26:53 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/wLZHbls/PTGr5mK2fwycXKG6B09/Mb+U=
Message-ID: <4B1EE0BD.7020403@extendedsubset.com>
Date: Tue, 08 Dec 2009 17:26:53 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp>
In-Reply-To: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
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: Tue, 08 Dec 2009 23:27:07 -0000
Martin Rex wrote: > > The secure TLS renegotiation _ONLY_ assures that the TLS endpoint > can not be tranferred among different peers without their _consent_ > during renegotiation. An MitM attacker is someone acting without consent. "Consent" isn't relevant, unless you're suggesting there are systems intentionally handing out secret key material. > As long as switching of the identity is permitted during renegotiation > (which it currently is), there is only a vague concept of > "party" at the other end. The remote party may be a physically hardened and tamper-resistant crypto module, or it may be some set of shared processes operating across a "cloud". In that sense it is nebulous, but that is outside the scope of the protocol. After this fix, the TLS concept of "remote party identity" becomes maximally "the identity established by the union of all valid and correct credentials validated during the establishment of a connection state on this connection, and transitively to all connections sharing at least one master_secret". For example, given the basic assumptions about the remote endpoint (it isn't pwned), you can believe all those credentials came from the same web browser. An application protocol is free to require its clients and servers to apply credentials more conservatively, of course. I suspect you would prefer application protocols to use a more minimal sense interpretation of identity, such as "the credentials validated during the establishment of just this one connection state". But this isn't sufficient for some uses of https and it is ambiguous for application data interleaved with handshake messages, so the maximal interpretation is actually better defined than yours. >>> If we make any recommendations for TLS libraries it should be to >>> not do renegotiation unless the application asks for it by >>> registering a callback. > > Clients usually do _not_ want renegotiation, but they have no say Some clients prefer renegotiation because they believe it lends confidentiality to the "public" client certificate. > in the TLS handshake. It is the Server which decides whether to > ask for a certificate on the initial handshake or whether the > server wants to make up his mind only after having seen the clients > request. Really it should be defined as part of any application protocol using TLS. > The issue is often usability / user-experience. If you ask a Browser > for a certificate on the initial connect, it will result in a popup > windows to the user, even if that user has no certificate. It > is possible to configure the browser to suppress this popup, > but often the browser has only a single configuration option > that says "select automatically", and that does actually two > different things, i.e. use a client certificate when the request > from the server matches exactly one client cert -- an the latter > is something one might want _not_ to happen automatically--in > contrast to automatic reply that no client cert is available. A. Yes, that's how browsers work. B. The number of applications which are "browsers" pop-up "choose a client cert" dialogs is small, I can think of four or five (actively maintained). This has got to be a tiny fraction of TLS client applications, even if it is the most visible and familiar for most people. > The get-style API is _the_only_ API that I provide to our applications. > Besides, I'm coming from the GSS-API world, and there never was > a callback API. > > If you think that get-style API is dangerous, then you seem to be > quite unaware about the risks involved with some of the callback APIs > (besides being difficult to use in distributed architectures). Then you can call the TLS library in a loop to invert the call. > TLS peers should check the peer's ID before they start sending > or receiving any data over the newly established TLS session. For current (pre-fix) https servers, the client's Finished message can be the most important thing it sends. > Apps protocols that infer from a successful TLS handshake that > previously received plaintext data is authenticated suffer from > a serious apps-level design flaw. > > Abusing GSS-API or TLS as an OTP plaintext authentication scheme > is IMHO a severe APPS design flaw. The ability to complete a > TLS handshake (or to establish a gssapi security context) > does not, by itself, convey any kind of intent. It's up to the app layer to define 'intent' the events exposed by the API, based on the stated and implied guarantees of the protocol spec. > Apps that infer intent from this, should really rethink their > flawed architecture. No, the design flaw was in SSLv3. It regressed on a fundamental security guarantee of SSLv2 and no one (including the spec writers) realized it at the time. - Marsh
- [TLS] Summarizing identity change discussion so f… Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Eric Rescorla
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Stefan Santesson
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- [TLS] OpenPGP Certs for TLS [was: Re: Summarizing… Daniel Kahn Gillmor
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Nelson B Bolyard
- Re: [TLS] Summarizing identity change discussion … Nasko Oskov
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)