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

<home_pw@msn.com> Wed, 10 January 2007 22:36 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4m3L-0005Bb-Vr; Wed, 10 Jan 2007 17:36:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4m3L-0005BN-2e for tls@ietf.org; Wed, 10 Jan 2007 17:36:15 -0500
Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4m3J-00009h-Ac for tls@ietf.org; Wed, 10 Jan 2007 17:36:14 -0500
Received: from hotmail.com ([65.55.131.27]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 10 Jan 2007 14:36:13 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jan 2007 14:36:12 -0800
Message-ID: <BAY126-DAV170D705159BDA85247456E92B20@phx.gbl>
Received: from 70.142.20.165 by BAY126-DAV17.phx.gbl with DAV; Wed, 10 Jan 2007 22:36:11 +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: martin.rex@sap.com
References: <200701102032.VAA12262@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
Date: Wed, 10 Jan 2007 14:36:10 -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: 10 Jan 2007 22:36:12.0506 (UTC) FILETIME=[BB32CBA0:01C73507]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
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,

I don't why the claim on the EU Directive is true, as TLS 
Evidence contains a mandatory "opt-in" mechanism. And, I 
assert, neither of the authors is arguing their case very 
well in the document or their explanations given this is a 
transnational audience.

> OK, I'll try to make it short:
>
> There is absolutely NONE, ZERO, NIL chance that this can 
> be used
> in customer<->business relationsships in the European 
> Union, because
> it is incompatible with the EU data protection directive 
> in many ways.
>

Despite pro forma optin mechanism compliance, its normal in 
US practice for US companies to subvert the Euro-intent on 
such opt in regimes using safe harbor and other procedural 
tricks : in the US, you will find that as a consumer one 
cannot connect to one's commodity service provider if you 
FAIL TO AGREE TO OPT IN to the data retention policy.

US practice on "privacy-regime subversion" goes further: the 
politics of Federal and State governments often manipulate 
public policy (usually and LEGITIMATELY by funding mandates) 
so that the insurers inevitably set the audit/practices 
standards so all providers REQUIRE the retention policy, 
thus subverting the consumer-protective optin policy intent, 
set by the EU Directive. but its America! They get to do 
what they want, too, for their own consumer standards!

This is just like today: phone a US health account insurer 
to discuss a claim, and it will tell you they are recording 
the call "for quality purposes". You can opt out, and thus 
the provider will simply drop the call, interdicting "phone" 
support... Your optin choice! Of course, it's a semantic lie 
(the "quality" part; its their to collect evidence of your 
claim fraud...); but this is reality for consumers. If YOU 
don't drop the call your side, post notification, you have 
accepted their policy by failing to opt out. The legal 
presumptions have been set to suit this bias, in the US 
sphere. And, we just say a manual legal-obligation passing 
protocol in effect. Could TLS Evidence do the same, for the 
web-equivalent via https? That is the real question the 
authors are posing.

note, I'm not saying to IETF: don't do TLS-Evidence-type 
obligation passing protocols: I cant, having proposed them 
myself in similar forums, and can see great value in 
instrumenting privacy policy (and other 
"battle-of-the-terms" negotiations.

But, on "wiretapping", we ALL ON THE SAME SIDE, we have to 
move beyond good/evil level debate over 
wiretapping/data-retention etc. As US govt policy has clear 
given ground - by acceding to decent confidentiality 
channels in standards - we have to reciprocate and thus move 
the privacy debate on... beyond "sticks and stones" grade 
name calling debates of the last 20 years.

TLS Evidence is broken in terms of SSL architecture; but it 
can be fixed. The only question is, do we want to, and is it 
the right timing? For example, should IETF simply wait 2-3 
years until the US national id card debate is more settled, 
first?

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

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