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

"Mark Brown" <mark@redphonesecurity.com> Fri, 12 January 2007 02:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Bs3-00051y-Uf; Thu, 11 Jan 2007 21:10:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Bs3-0004xZ-2V for tls@ietf.org; Thu, 11 Jan 2007 21:10:19 -0500
Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5Bs0-0004yf-MB for tls@ietf.org; Thu, 11 Jan 2007 21:10:18 -0500
Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id B03598297; Thu, 11 Jan 2007 20:10:13 -0600 (CST)
From: Mark Brown <mark@redphonesecurity.com>
To: martin.rex@sap.com
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00<
Date: Thu, 11 Jan 2007 20:11:49 -0600
Message-ID: <001f01c735ef$050889d0$6801a8c0@rps.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acc12y6kY5a1G32JT5iPiOKgxbUVNgAEKGtQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
In-Reply-To: <200701112347.AAA05530@uw1048.wdf.sap.corp>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: tls@ietf.org
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

Martin,

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

"1. Member States shall provide that the controller must implement
appropriate technical and organizational measures to protect personal data
against accidental or unlawful destruction or accidental loss, alteration,
unauthorized disclosure or access, in particular where the processing
involves the transmission of data over a network, and against all other
unlawful forms of processing.
"Having regard to the state of the art and the cost of their implementation,
such measures shall ensure a level of security appropriate to the risks
represented by the processing and the nature of the data to be protected.

This directive makes it clear that it will hold organizations to the highest
standard of security measures in this case: "in particular where the
processing involves the transmission of data over a network."  But obviously
TLS session encryption satisfies this standard.  And obviously, persisting
the packets does not degrade the encryption.  So by persisting the packets,
you've satisfied the highest standard.

Regarding card processing:

> > i know approximately nothing of EU data protection requirements, but
> > something about US and payment card industry data protection
> > requirements.  if there is PII or payment instrument information in the
> > "audit record" produced by this proposal, then that audit record must
> > either be modified to eliminate or secure the PII/PI sections, defeating
> > the purpose of the record, or it must be treated, in its entirety, as
> > PII/PI.  that second option is particularly onerous.
> 
> Interesting!  So this problem may actually exist in the US as well,
> albeit not as thorough as here.

In recent years Visa's CISP program became mandatory.  It is available here:

http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cis
p_PCI_Data_Security_Standard.pdf

Page 4: "Requirement 3: Protect Stored Data
Encryption is the ultimate protection mechanism because even if someone
breaks through all other protection mechanisms and gains access to encrypted
data, they will not be able to read the data without further breaking the
encryption. This is an illustration of the defense in depth principle."

Visa's CISP clearly regards encryption (and good key management) highly,
since here "Encryption is the ultimate protection mechanism."  TLS
accomplishes all this excellently. 

--mark


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