Re: [TLS] TLS, PKI,

Martin Rex <mrex@sap.com> Wed, 21 July 2010 19:46 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5DA3A694A for <tls@core3.amsl.com>; Wed, 21 Jul 2010 12:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.687
X-Spam-Level:
X-Spam-Status: No, score=-8.687 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 be7qeCIJLqgh for <tls@core3.amsl.com>; Wed, 21 Jul 2010 12:46:06 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 514283A68E8 for <tls@ietf.org>; Wed, 21 Jul 2010 12:46:05 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o6LJkJP7004778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jul 2010 21:46:19 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201007211946.o6LJkJ6I005355@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Wed, 21 Jul 2010 21:46:18 +0200
In-Reply-To: <4C3D2905.1090800@extendedsubset.com> from "Marsh Ray" at Jul 13, 10 10:03:33 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS, PKI,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 19:46:07 -0000

Marsh Ray wrote:
> 
> Specifically it was designed to allow the masses to make secure* 
> connections to e-retailers with which they had no prior agreement. 
> Having a pre-trusted third party perform the introduction is probably 
> the only way to accomplish that. Trust-on-first-use and PGP web-of-trust 
> type models were simply not going to get the shoppers online.

Trust-on-first-use would have worked just fine, and would be
several magnitudes more secure than the mess there is with the
dozens of independent, pre-trusted and equivalent roots.

In case you forgot, Browsers orignally used to show a warning
popup when you switched from plain HTTP to HTTPS, and you had
to checkmarked to not see that warning anymore -- which negates
your point that trust-on-first-encounter would not have worked.


> 
> *secure = Secure enough to convince people it's safe to type in their 
> credit card online, yet not so secure that it presented a real obstacle 
> to government decryption.

There is no need to convince people.  This is why social engineering
is so much easier and works so reliably compared to attacking
encrypted communication.


> 
> I may "trust" every CA approved by my browser vendor in the sense that I 
> estimate with 99% probability that that CA will not act in a way which 
> diminishes my effective security.


The concept that you describe is commonly known as "faith".
"trust" in the security area used to have a very different meaning.


-Martin