IETF Logo Mail Archive

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

Ralph Holz <ralph-tls-tum@ralphholz.de> Mon, 04 October 2010 15:53 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 4ADB83A6FD5 for <tls@core3.amsl.com>; Mon, 4 Oct 2010 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 eEIHPapNA6SG for <tls@core3.amsl.com>; Mon, 4 Oct 2010 08:53:44 -0700 (PDT)
Received: from serverkommune.de (serverkommune.de [88.198.12.136]) by core3.amsl.com (Postfix) with ESMTP id 238883A6D29 for <tls@ietf.org>; Mon, 4 Oct 2010 08:53:43 -0700 (PDT)
Received: (qmail 18176 invoked by uid 89); 4 Oct 2010 17:54:37 +0200
Received: from serverkommune.de (HELO ?131.159.20.131?) (ralph@serverkommune.de@88.198.12.136) by serverkommune.de with ESMTPA; 4 Oct 2010 17:54:37 +0200
Message-ID: <4CA9F8BC.3090704@ralphholz.de>
Date: Mon, 04 Oct 2010 17:54:36 +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
To: tls@ietf.org
References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 04 Oct 2010 15:53:45 -0000

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.

-- 
Best regards,
Ralph

v2.23.0 | Report a Bug | By Email