Re: [TLS] TLS, PKI,

Marsh Ray <marsh@extendedsubset.com> Wed, 14 July 2010 03:03 UTC

Return-Path: <marsh@extendedsubset.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 98D2A3A68BE for <tls@core3.amsl.com>; Tue, 13 Jul 2010 20:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.69
X-Spam-Level:
X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_50=0.001]
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 z7w5nD7zzlMT for <tls@core3.amsl.com>; Tue, 13 Jul 2010 20:03:26 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9BCAE3A6844 for <tls@ietf.org>; Tue, 13 Jul 2010 20:03:26 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OYsFz-000AFh-N8 for tls@ietf.org; Wed, 14 Jul 2010 03:03:35 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BFC4A6344 for <tls@ietf.org>; Wed, 14 Jul 2010 03:03:34 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19Vup6yUaSo62ylfFeu9Ktf59etC1p/O28=
Message-ID: <4C3D2905.1090800@extendedsubset.com>
Date: Tue, 13 Jul 2010 22:03:33 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5
MIME-Version: 1.0
To: tls@ietf.org
References: <201007140006.o6E06JUx017259@fs4113.wdf.sap.corp> <4C3D15C5.1090307@REDHAT.COM>
In-Reply-To: <4C3D15C5.1090307@REDHAT.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS, PKI,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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, 14 Jul 2010 03:03:27 -0000

On 07/13/2010 08:41 PM, Robert Relyea wrote:
> On 07/13/2010 05:06 PM, Martin Rex wrote:
>>
>> If SSHv1 would have required CA-signed X.509 certs in its initial
>> shipment, it would have taken MUCH longer to become popular, if at all.
>>
> Compared to SSL, SSH is still not popular, which sort of negates your point.
>
> SSL is designed to allow you to make secure connections for the masses.

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.

*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.

So be careful what you ask for, those requirements were met and we've 
been living with those design decisions for so long now it's hard to 
have an objective perspective on proposed alternatives.

Who can say why one protocol is considered "secure" in its users' 
opinion? SSHv2 is a nice, cleanly designed protocol. "Why can't SSL just 
work like SSH?" they ask. Yet it's inherently vulnerable to MitM for the 
initial connection and amounts to users installing a permanent exception 
for every cert mismatch warning. The default configuration for many 
clients (including PuTTY) leaves it vulnerable to a trivial downgrade 
attack to SSHv1 which can be vulnerable to plaintext injection. These 
are known issues, but for some reason they are disregarded by those who 
like to think of SSH as some kind of gold standard.

I dislike oligarchies as much (or more) than the next guy, but IMHO we 
actually need more of it in the CA department. I don't want a big 
inclusive society of hundreds of CAs all trusted without limit by my 
browser. I personally believe the appropriate number of CAs for my 
browser is somewhere between 5 and 10. I want just enough to ensure 
reduncancy and allow for some market competition, and no more.

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. But if I trust 200 of them then my 
estimation of the probability that none will fail me drops to 13% 
(0.99^200).

Of course, based on their observed performance I wouldn't trust many of 
them with a 10 foot pole. :-) Like the one with the login/password form 
on their non-SSL home page (you know who you are).

- Marsh