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

Geoffrey Keating <geoffk@geoffk.org> Mon, 04 October 2010 16:17 UTC

Return-Path: <geoffk@geoffk.org>
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 906273A6FD9 for <tls@core3.amsl.com>; Mon, 4 Oct 2010 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 eaD3dbPlBQUk for <tls@core3.amsl.com>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 76DC93A6FC5 for <tls@ietf.org>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id CDED833D0FD; Mon, 4 Oct 2010 16:18:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Ralph Holz <ralph-tls-tum@ralphholz.de>
References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9F8BC.3090704@ralphholz.de>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 04 Oct 2010 09:18:24 -0700
In-Reply-To: <4CA9F8BC.3090704@ralphholz.de>
Message-ID: <m2r5g6j5in.fsf@localhost.localdomain>
Lines: 35
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: tls@ietf.org
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: Mon, 04 Oct 2010 16:17:31 -0000

Ralph Holz <ralph-tls-tum@ralphholz.de> writes:

> Hi,
> 
> > But keep in mind that few TLS clients (such as browsers), currently
> > support "pinning" of PKIX-authenticated server certs, so that on future
> > connects only the very same server cert (with user-authenticated
> > attributes other than DNS f.q.d.n) will be accepted from that server.
> > In is very common misbehaviour in TLS clients to accept arbitrary other
> > server certs on future connects, as long as the DNS f.q.d.n matches.
> 
> I have found during a few tests that some companies which give different
> IPs for the same DNS name also run some servers with different certs
> than the "main one". A closer look at the certs revealed that they had
> been issued for the same domain and had been signed by the same CA, i.
> e. they were perfectly valid. Pinning certs would prohibit this kind of
> behaviour.
> 
> Although I am not sure it is intentional - my thought was that these
> servers were just misconfigured (older cert?), as only very few
> exhibited this behaviour.

Some CAs license their certificates for use on a single server.  If
these companies were using one of these CAs, they may have bought
multiple certificates for the same DNS name.  This might be done even
if the CA doesn't require it, as a security/reliability measure, so
that machines do not need to share private keys.

This can also happen for the same IP address, if it's a load balancer
with several servers behind it.

It can also happen if the systems serve different combinations of DNS
names: one machine serves www.a.com and another serves both
mail.a.com and www.a.com so they have different certificates.