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

Martin Rex <martin.rex@sap.com> Fri, 12 January 2007 15:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OGv-00027L-DS; Fri, 12 Jan 2007 10:24:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OGt-00023u-NW for tls@ietf.org; Fri, 12 Jan 2007 10:24:47 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OGp-0004ZO-7m for tls@ietf.org; Fri, 12 Jan 2007 10:24:47 -0500
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA00501; Fri, 12 Jan 2007 16:24:24 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701121524.QAA17965@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
To: ben@layer8.net
Date: Fri, 12 Jan 2007 16:24:23 +0100
In-Reply-To: <45A6FD47.6040207@layer8.net> from "Benjamin Black" at Jan 11, 7 07:15:19 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
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

Benjamin Black wrote:
>
> Martin Rex wrote:
> > So an application-level approach should not only standardize the
> > tagging of to-be-signed content, it should actually provide two
> > seperate tags resulting in two independent signatures, one
> > over all the data that ought to be authenticated during
> > processing of the transaction and one signature over only
> > the data that is to (and legally permitted to be) persisted.
> 
> sounds like a job for ws-*, not tls.

XML/XMLsig is probably OK.

WS-Security (SOAP,SAML) - better not.


There appears to be a serious misconception about what value
"assurance" and "assurance levels" could provide to the business
world.  In many areas it is not only painful and entirely useless,
it is even counter-productive in providing a false sense of security.

High assurance in software, hardware, policies and policy processing
is not going to improve accuracy and/or truth of the communicated
or stored information or communication.  And digital signatures
blindly applied to arbitarary collections of data are a real problem
for fixing or deleting inaccurate or untrue information.

Appropriately engineered cryptographic integrity protection for
data (in transit AND at rest) to provide resistance to tampering
is perfectly sufficient.

Businesses are collecting and producing data in the multi-megabyte
per day range.  9 years ago, the largest database among our
customers was 700 Gigabytes.  I don't know what is common today,
but I assume that several have long crossed the Terabyte mark.

So it is a sad fact that a lot of inaccurate information is processed
and stored by businesses every day, and applying digital signatures
on raw communication data will hardly have any benefits for the
businesses, but TLS Evidence will come at a cost and
create a significant performance impact (latency).

I mentioned it before, for Online shopping it will be pretty useless.
See
      http://www.heise.de/newsticker/meldung/83574

(sorry, it's all German).  Amazon had put up Sony&IBM laptops at less
than EUR 20 in their online shop and of course, several customers
ordererd them.  This is why businesses make sure that such offers
are not binding, because error like these happen every once in
a while.  This illustrate just what a stupid idea TLS Evidence would
be in these scenarios.



Maybe the President could claim that he received [EAL6] assured evidence
from intelligence that Saddam was working on nuclear WMD without
actually lying.  He probably is using highly assured equipment and
is communicating over highly assured communication links only.
Highly assured equipment higly assures that garbage in will
result in highly assured and expensive garbage out.


I also think that trying to provide any level of "non-repudiation"
on content (especially raw content) is just the opposite of where
everyone should be going.

Many US supermarkets have had a customer friendly return policy
for many years.  In Germany we didn't have it for quite a long time,
it came up a few years ago.  For online&telephone shopping, a very
customer-friendly return policy was enacted as law just 3/4 years ago.
Today, we usually do not have disputes about the content of an order
that was placed, but rather about characteristics or quality of the
product, inaccuracies of the advertisement and intend of the customer
placing the order.


-Martin

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