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

"Jeffrey A. Williams" <jwkckid1@ix.netcom.com> Mon, 04 October 2010 17:44 UTC

Return-Path: <jwkckid1@ix.netcom.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 970B83A6FE5 for <tls@core3.amsl.com>; Mon, 4 Oct 2010 10:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.352
X-Spam-Level:
X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 sFOIPOtaSplJ for <tls@core3.amsl.com>; Mon, 4 Oct 2010 10:44:58 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id E60FB3A6FB7 for <tls@ietf.org>; Mon, 4 Oct 2010 10:44:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=K1O2uKCoiksagT9bNueJQtRUqrS8mNP72z1galI76kNvgLARj0VilRCDRBHq9BmO; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1P2p6n-0004oy-6s; Mon, 04 Oct 2010 13:45:53 -0400
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 4 Oct 2010 13:45:53 -0400
Message-ID: <20174209.1286214353231.JavaMail.root@elwamui-royal.atl.sa.earthlink.net>
Date: Mon, 4 Oct 2010 12:45:53 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
To: Ralph Holz <ralph-tls-tum@ralphholz.de>, tls@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688ceb27319d864056ba25554909447d0a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.46
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.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: Mon, 04 Oct 2010 17:44:59 -0000

Ralph and all,

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


-----Original Message-----
>From: Ralph Holz <ralph-tls-tum@ralphholz.de>
>Sent: Oct 4, 2010 10:54 AM
>To: tls@ietf.org
>Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
>
>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
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827