[TLS] draft-housley-evidence-extns-00 worse than key escrow

Martin Rex <martin.rex@sap.com> Mon, 08 January 2007 13:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ut0-0001da-TU; Mon, 08 Jan 2007 08:50:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3usz-0001b1-60 for tls@ietf.org; Mon, 08 Jan 2007 08:50:01 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3usx-00078W-Po for tls@ietf.org; Mon, 08 Jan 2007 08:50:01 -0500
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id OAA21495; Mon, 8 Jan 2007 14:49:53 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701081348.OAA27556@uw1048.wdf.sap.corp>
To: tls@ietf.org
Date: Mon, 08 Jan 2007 14:48:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc:
Subject: [TLS] draft-housley-evidence-extns-00 worse than key escrow
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

What has become obvious from the disscussion so far is not only
that the draft-housley-evidence-extns-00 is absolutely useless
for purposes of creating receipts for internet online commerce,
it's primary intention is to completely subvert the TLS protocol
in order to provide a means for law enforcment agencies to
collect evidence of thought-to-be private (tele)communications
for direct use in court, in a quality that will make it difficult
to impossible deny/repudiate.

10 years ago, we thought that mandatory key escrow would be the worst
that could happen to computer security.  This proposal is worse by
a significant margin.

The obvious drawback of key escrow is, that with the keys one can
not only reveal the protected communication, but also trivially
"fabricate" evidence, which would significantly impair/ruin the quality
of "wire-tapped" communcations as (sole) evidence in court.

With the TLS evidence approach, requiring EAL6+ crypto hardware and
keystores on every telecommunication device and having them sign
the entire raw communication, the wire-tapped can not only be used
for intelligence purposes and further investigations leading to
real evidence, it can be used directly as evidence against either
or both of the unsuspecting and unconsenting communication peers.

For the usage scenario that Mark is looking at, the communication
peers are going to be an end user's telecommunications device on
one side and some network operators phone switch on the other.
I don't know whether he's thinking of VoiP or the next generation
of mobile phones.

So the key on the "users side" (plus a certificate by an
government-authorized CA) would likely be a requirement for the
device to access the phone switch, and it would first of all
identify the device and communications from this device,
rather than an actual user.  There is no intention to notify or
even ask for consent for a signed wire-tap evidence, of course.


-Martin
 


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