Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to

Martin Rex <martin.rex@sap.com> Thu, 11 January 2007 21:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H575W-0001bv-3d; Thu, 11 Jan 2007 16:03:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H575V-0001bi-5F for tls@ietf.org; Thu, 11 Jan 2007 16:03:53 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H575M-0002uj-Uw for tls@ietf.org; Thu, 11 Jan 2007 16:03:53 -0500
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA29169; Thu, 11 Jan 2007 22:03:26 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701112103.WAA03004@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to
To: stefans@microsoft.com
Date: Thu, 11 Jan 2007 22:03:26 +0100
In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF01D6E0EB7@EA-EXMSG-C307.europe.corp.microsoft.com> from "Stefan Santesson" at Jan 11, 7 07:39:24 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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

Stefan Santesson wrote:
> Martin Rex wrote:
> > A well engineered approach would not use a shotgun approach to
> > security, but instead a tailored design that meets exactly
> > the needs of the application, can be used for programmatically
> > checking consistency an can create digital tamper-resistant
> > proofs of transactions that contain all and only the necessary
> > information that is necessary
> 
> Yes, don't we all wish we had that. Especially that we could agree on
> what "all and only the necessary information that is necessary" is.

You got me wrong.

> >                                -- in which case it will be
> > possible make it conforming with individual, case-specific
> > legal and buisiness requirements.

Instead of having to redesign and rewrite the entire application protocol
stack for every use case in order to accomodate what data will and
will not become part of the TLS Evidence, one can make it a configuration
option for the customer in the application.  So all of the attributes
that the backend wants to get signed will be tagged as such in
the request from the backend to the frontend.  Auxiliary information
will go untagged and not be included in the signature.  Because
the app knows what it wants signed, it can actually verify that it
receives what it is looking for.


> 
> Another 10 years will pass before we get there unfortunately.
> In the meanwhile we will continue to conduct business based on
> passwords and totally spoofable security.

A data-agnostic TLS-Evidence is still spoofable because of a lack
of assurance of the participating software components.


>
> In security, perfect has always been the enemy of the good.

Perfect forward secrecy is an enemy of TLS Evidence, and
I prefer the former by a significant margin. (I mean Perfect Forward
Secrecy as a design goal of the entire system, not only as
an isolated characteristic in the threat model for a particular
network link).


-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls