Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata
<home_pw@msn.com> Thu, 11 January 2007 20:38 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56go-00007h-66; Thu, 11 Jan 2007 15:38:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56gm-00006m-6R for tls@ietf.org; Thu, 11 Jan 2007 15:38:20 -0500
Received: from bay0-omc3-s37.bay0.hotmail.com ([65.54.246.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56gL-0005WV-6x for tls@ietf.org; Thu, 11 Jan 2007 15:37:55 -0500
Received: from hotmail.com ([65.55.131.18]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 12:37:48 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 12:37:48 -0800
Message-ID: <BAY126-DAV83E5AAB1932AC4F19AE1392B10@phx.gbl>
Received: from 70.142.20.165 by BAY126-DAV8.phx.gbl with DAV; Thu, 11 Jan 2007 20:37:45 +0000
X-Originating-IP: [70.142.20.165]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
To: Mark Brown <mark@redphonesecurity.com>, tls@ietf.org
References: <015c01c73596$2d61a910$6801a8c0@rps.local>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata
Date: Thu, 11 Jan 2007 12:37:44 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 11 Jan 2007 20:37:48.0142 (UTC) FILETIME=[5B14A0E0:01C735C0]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: "'Kemp, David P.'" <DPKemp@missi.ncsc.mil>
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
If it's the intent to solve the problem mentioned, this was not stated in the document. Not even a hint! What I am hearing is that its intended that TLS does more than name a communication port, open it, and secure record flow over the wire; it will henceforth address the Proof problems (PoO, PoS PoD, PoR) for (opaque) information objects by linking signatures flowing over the read and write channels. If the un-definable NR conditions are satisfied when asserting a X.509 bit flag called NR, one can even assert it has PoXwithNR semantics. A (signed) SAML assertion might accompany the signature, to enable mechanism-specific authorization functions (like dual signing is required, no signing on holy days, signature-capture required, the officer's secretary can generate delivery - but not read - receipts). Specifically, its intended to address the SSL offloading pattern in data centers, where loadbalancers often strip SSL in the aggregation layer of the data center, before delivering http payload to the access layer of the server farm (or one of its colos). Thus TLS Evidence also addresses engineering issues to do with (I) managing sticky TLS sessions so TLS fragments and/or cleartext fragments/records are forwarded appropriate through the switches (II) establishing the assurance of particular SSL deployment models in data center configurations (c) complex cases of a hypermedia application multiple managing parallel session/connections, the impact on whom TLS Evidence will now consider in detail. I'm supportive of ALL this, to the level of experiment. I don't think it will be long before we have reinvented the CCITT X.400 1988 security model ("mostly trust the messaging relays, dummy!" )... but lets see where it goes, and how it differs. Whereas with secure X.400 one attached the semantics of the generic signing mechanisms by defining yet another toolkit service APDU to the trusted MTS transport/relaying protocol, in TLS Evidence this will be signaled by cert extension values that signal the service intended for a given "TLS Evidence". And, again like X.400's MTS-based security model, multiple signatures/evidences might be involved to implement a bidirectional assurance such as PoR (which builds upon the PoD signature attached by the loadbalancer, to become a PoR signature/evidence created by the TLS endpoint identified by the full https URI) I think this has to both an https.next and SSL effort tho. And, https is woefully underspecified as to the core, layer 7 security model that is shared widely amongst the many usage model out there. But ,there is plenty of expertise in trusted messaging relay security models. We can draw upon this, to flesh out https properly, particularly if its URIs and connection practices are going to be a critical component of the TLS Evidence semantics. I would see some backlash tho, from certain IETF quarters: it could get political quickly; a lot of ego is involved, here. It WOULD BE quite amusing if, via SSL/TLS and TLS Evidence, the MTS trust model wins out over the writer-to-reader model of S/MIME (and its predecessors). ----- Original Message ----- From: "Mark Brown" <mark@redphonesecurity.com> To: <home_pw@msn.com>; <tls@ietf.org> Cc: "'Kemp, David P.'" <DPKemp@missi.ncsc.mil> Sent: Thursday, January 11, 2007 7:35 AM Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata > Peter, > I can see how TLS Evidence could be used as David suggests in his terse > comment about: "(1-to-many) persistent authentication". > You're right we > haven't talked about this use of TLS Evidence before. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Stefan Santesson
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Nelson B Bolyard
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Omirjan Batyrbaev
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Steven M. Bellovin
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.