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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mu1-0007zg-PF; Fri, 12 Jan 2007 08:57:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mu0-0007vz-96 for tls@ietf.org; Fri, 12 Jan 2007 08:57:04 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mtt-0006X1-6Y for tls@ietf.org; Fri, 12 Jan 2007 08:57:04 -0500
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id OAA10366; Fri, 12 Jan 2007 14:56:39 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701121356.OAA16779@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
To: mark@redphonesecurity.com
Date: Fri, 12 Jan 2007 14:56:23 +0100
In-Reply-To: <001f01c735ef$050889d0$6801a8c0@rps.local> from "Mark Brown" at Jan 11, 7 08:11:49 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: 769a46790fb42fbb0b0cc700c82f7081
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

Mark Brown wrote:
> 
> Precautions as described in TLS Evidence 6.2 use security measures that
> prevent accidental loss, alteration, and unauthorized disclosure or access.
> They are strong enough to satisfy Visa's CISP.  There should be no problem.
> 
> If the business determines that it has a business reason to store the TLS
> Evidence -- you would need that to justify buying the disk drives -- then
> that business reason is the business's justifying need under the directive
> you cite.
> 
> http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html
> SECTION VIII - CONFIDENTIALITY AND SECURITY OF PROCESSING
> Article 17 Security of processing

I can not really comment on the US aspect of this, but for the European,
and in particular for the German aspect, you are plain wrong.

Since you reference the EU data protection directive, you seem to
have entirely missed the much more important obligations from
Article 6 (b,c,d,e).

It is not up to the business to determine necessary data, and if
they process it (persisting counts as processing according to Art 2 b),
**they** have, among other things, to ensure accuracy of personal data,
and fix or delete when they learn about inaccuracy.

Although there is an clear and obvious business need for an ISP to memorize
the IP address to customer mapping for a flatrate DSL customer who is
online, the german court clearly declined that need after the customer
hangs up.  The courte issued an order to delete the record after hangup,
and they also prohibited the ISP from further collecting (let alone storing)
volume transfer data for the flatrate customer.  The court set out
a fine of 100000 Euro or 6 month in Jail for the CEO of the ISP for
further non-compliance.  This was about the data of ONE SINGLE CUSTOMER!
That ruling was upheld by the german supreme court.

As far as the blind raw communication capture approach by TLS Evidence
approach is concernd -- just "accidentally" include (entirely) unnecessary
and possible even incorrect data in the datastream and wait until the
business has persisted the TLS Evidence.  Then you can force the business
to either delete the unnecessary data or to fix or delete the incorrect
data in the persisted record.  The EU data protection directive doesn't
care whether fixing or deleting parts of the record invalidate a
digital signature.


-Martin

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