Re: [TLS] Security concerns around co-locating TLS and non-secure

Martin Rex <mrex@sap.com> Wed, 10 November 2010 03:24 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066E33A67F3; Tue, 9 Nov 2010 19:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.817
X-Spam-Level:
X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_BIZOP=0.7]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx+DflUOBW2a; Tue, 9 Nov 2010 19:24:53 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C612A3A67AE; Tue, 9 Nov 2010 19:24:52 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oAA3PFWd018016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 04:25:16 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011100325.oAA3PEBB021028@fs4113.wdf.sap.corp>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure
To: marsh@extendedsubset.com
Date: Wed, 10 Nov 2010 04:25:14 +0100
In-Reply-To: <4CD98A16.4070004@extendedsubset.com> from "Marsh Ray" at Nov 9, 10 11:51:18 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -0800
Cc: paul.hoffman@vpnc.org, tls@ietf.org, tsvwg@ietf.org, Nicolas.Williams@oracle.com
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 03:24:54 -0000

Marsh Ray wrote:
> 
> > SSH has been so successful in large part because leap-of-faith works
> > rather well -- it has a very small window of vulnerability, a very big
> > vulnerability, yes, and requiring persistent storage, true, but
> > difficult to exploit without users eventually noticing.
> 
> I know I read a study somewhere of what users (a university setting I 
> think) typically did when presented with the "WARNING: REMOTE HOST 
> IDENTIFICATION HAS CHANGED!...Are you sure you want to continue 
> connecting (yes/no)?" question. I think the results were pretty dismal.

How surprising.  If you furnish your users with software that will
perform a social engineering attack on your users whenever an
outside attacker asks for it, why should you expect a different
reaction?  (btw. the SSH clients that I'm using do not suggest
to override a changed host key and in particular don't offer to
do so with a simple "Y" keypress, they just fail.)


Curiosity kills cats and makes social attacks succeed.


If you send an intriguing Email with a dangerous attachment to
a significantly large fraction of employees in a company, _some_
of the users _will_ double-click the attachment -- guaranteed.

For something that sounds moderately interesting it may be
around ~10% of the recipients blindly relying on the safety of
the AV-software to protect them from dangerous stuff.



The underlying problem with the "TLS PKI" is that it is an
ants-level solution to ant-level problems.  "Smells like its from
our nest -- just let it in".


Evolution caused more advanced species to use more sophisticated
schemes of trust and protection against impersonation, and I really do
not understand why there is so much resistance against evolving
TLS security beyond ants level.

All trust decisions performed by more advanced species are based on
leap-of-faith on initial encounter and memorizing information for
validating future encouters of the same individuals (and things),
including recognizing ones parents.


Personally, I find it frightening just how wildly successful
a tool like Firesheep is in attacking services like GoogleMail,
Hotmail, Facebook, ebay and sorts.  If the services themselves
already subvert the security so throughly by doing parts or most
of the communication totally unprotected, then it seems pretty
pointless to discuss the (lack of) value of the commercial CA TLS PKI.


For a number of "selling" players around the TLS technology, the most
interesting part appears to be the business models / business opportunities,
not the security.  And for a number of "consumers" of the TLS technology
the most appealing part is continuity in authenticating end users
with weak passwords.


> 
> So, except in cases where explictly unauthenticated endpoints are 
> involved, isn't it reasonable that for WG discussions to presume that a 
> security protocol will be building upon some form of trust framework?

There will always be both.  Starting from scratch with no
trust framework, and integrating into an existing trust framework
(personal, home/family, organizational/corporate or governmental).


> 
> Or is there a new world happening where we're retreating from that 
> principle and we now expect systems to somehow bootstrap their own 
> security out-of-the-box or not get used at all?


There are out-of-band key distribution & personalization schemes,
One that is being used quite heavily around the globe is distribution
"SIM" cards.  Another one is TPM modules.  Or smartcards containing
public key crypto and credentials.

The most popular schemes are "bootstrapping" with leap-of-faith,
and bootstrapping with (simple|default|anything) passwords.

And "thanks to TLS" traffic encryption, password based authentication
schemes will be with us for very much longer...


-Martin