Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Ralph Holz <ralph-tls-tum@ralphholz.de> Tue, 05 October 2010 16:47 UTC

Return-Path: <ralph-tls-tum@ralphholz.de>
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 AF3C43A6F8B for <tls@core3.amsl.com>; Tue, 5 Oct 2010 09:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level:
X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292]
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 lWKHK4jmg6gD for <tls@core3.amsl.com>; Tue, 5 Oct 2010 09:47:43 -0700 (PDT)
Received: from serverkommune.de (serverkommune.de [88.198.12.136]) by core3.amsl.com (Postfix) with ESMTP id 4D7D53A6CE1 for <tls@ietf.org>; Tue, 5 Oct 2010 09:47:43 -0700 (PDT)
Received: (qmail 7722 invoked by uid 89); 5 Oct 2010 18:48:40 +0200
Received: from serverkommune.de (HELO ?131.159.20.131?) (ralph@serverkommune.de@88.198.12.136) by serverkommune.de with ESMTPA; 5 Oct 2010 18:48:40 +0200
Message-ID: <4CAB56E7.7000709@ralphholz.de>
Date: Tue, 05 Oct 2010 18:48:39 +0200
From: Ralph Holz <ralph-tls-tum@ralphholz.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
CC: tls@ietf.org
References: <20174209.1286214353231.JavaMail.root@elwamui-royal.atl.sa.earthlink.net>
In-Reply-To: <20174209.1286214353231.JavaMail.root@elwamui-royal.atl.sa.earthlink.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
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: Tue, 05 Oct 2010 16:47:44 -0000

Hi,

>   I am guessing here that you are in favor of pinning certs?
> If my guess is correct, can you tell us all why you are?

I am not sure I am in favour. The practical argument for it would be
that a changed certificate should be reason for a user to stop for a
moment and think. OK for now, maybe. However, many certs have life-times
of 1 year or 2. Given that one day we may visit many more https-secured
sites, we would likely see more false alerts again soon, too - precisely
the thing that Firefox has been criticised for when it introduced its
new warning dialogue.

On a more theoretical basis, I am also not sure if the 1:1 binding of
"one entity/identity - one key" is desirable.

Still, given the current PKI trust model and the current state of PKI as
such, I would probably vote with those in favour of pinning for the moment.

> I am not as there are instances where a perfictly valid cert
> is used but that the issuing CA has had their Cert database
> hacked or corrupted and a secondary Cert becomes necessary
> or at least preferrable as a temporary fix.  Of course such
> a cert would need to be issued by a different CA.

Well... listening to CAs and their EV statements, such things should not
happen too often anyway. It should not be a argument against pinning.

-- 
Best regards,
Ralph