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

"Mark Brown" <mark@redphonesecurity.com> Thu, 04 January 2007 20:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z3w-0002Ev-J8; Thu, 04 Jan 2007 15:19:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z3v-0002El-IE for tls@ietf.org; Thu, 04 Jan 2007 15:19:43 -0500
Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Z3t-0000ZO-IJ for tls@ietf.org; Thu, 04 Jan 2007 15:19:42 -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 B3C448258; Thu, 4 Jan 2007 14:19:38 -0600 (CST)
From: Mark Brown <mark@redphonesecurity.com>
To: martin.rex@sap.com, tls@ietf.org
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00
Date: Thu, 04 Jan 2007 14:21:11 -0600
Message-ID: <005a01c7303d$e081cdd0$6801a8c0@rps.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <200701041812.TAA01659@uw1048.wdf.sap.corp>
Thread-Index: AccwK/cOdC+yNwSpQea1njRccTJoRgAAhCIw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 1.1 (+)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc:
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,

> An attacker doesn't need to
> compromise/steal the keys if he can get data of his choice
> signed...

Here's how to get useful data of your choice signed using TLS Evidence:
spoof the app server to the server-side TLS layer.  Attacker could lurk
around in the DMZ and intercept calls to the app server, impersonate the app
server, and send data of your choice back to the TLS layer that's doing TLS
Evidence.  A simple deterrent: use IPsec between the DMZ-located TLS box and
the app server on the internal network.  Stronger approaches could be used.

Except for out of band (out of TLS session) subversion attacks or straight
impersonation (as above), it's not realistic to believe an attacker can
obtain useful, doubly-signed TLS Evidence for data of his choice.  TLS
Evidence is hard to forge and similarly hard to create for data of your
choice.

If the attacker can succeed in an out-of-band subversion effort, then it's
probably easier for an attacker just to bypass TLS Evidence and go straight
at the web app or system of record on the internal network.  In these cases
there's no TLS Evidence at all -- and you may have bigger problems on your
hands.

Let's say the attacker doesn't compromise the TLS server's keys, but wants
to subvert the web app in-band.  So the attacker attacks the app server
while using TLS Evidence.  If so, the TLS Evidence will show what the
attacker sent (the message that subverted the web app) and what the attacker
received (a ticket).  So if the server retains the TLS Evidence then they
can show who subverted the app and how they did it -- with the attacker's
own signature.  That would be a dumb move on the attacker's part, i.e.,
"Here's evidence of how I subverted your server and extracted a ticket --
now give me my reward."  Does your attacker prefer civil or criminal legal
problems?  

Let's say the attacker also destroys the server's TLS Evidence -- well, does
the attacker retain his own copy?  Does the attacker show his TLS Evidence
later when the server app's organization has no record of the ticket?  If
the attacker destroys all copies of the TLS Evidence, then it can't be used
in any attack, defense, etc.

If the attacker just subverts the client, then the server app won't think
that the attacker/client has paid for the ticket and won't issue the ticket.
Where's the attack?  Does the attacker pull out his own credit card and pay
for the ticket, via the subverted client?  Then the evidence will show it.
The subverted client will sign it, and the server will verify that the
signature is correct -- all before the ticket gets created or sent.

Are there better attacks to get data of the attacker's choice both TLS
Evidence-signed and useful to the attacker?

> See https://www.global-esign.com/
> for verification of legally binding digital signatures by a
> government accredited CA on CMS and signed PDFs (as for the
> Invoices of the German Internet Service Provider I mentioned).

I am sure that TLS Evidence uses not rely on the German national CA law.
TLS Evidence does not require a state-run Certificate Authority while the
German approach you mention does.  Because TLS is an International standard,
it doesn't make sense to embed dependencies on German laws (or Utah laws,
etc.) into TLS.

Let's skip the legal discussion in this forum.

--mark


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