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

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 4 Oct 2010 12:45:53 -0500 (GMT-05:00)

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 <[email-masked]>
>Sent: Oct 4, 2010 10:54 AM
>To: [email-masked]
>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
>[email-masked]
>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 [email-masked]
Phone: 214-244-4827

---

From: Ralph Holz <[email-masked]>
Date: Tue, 05 Oct 2010 18:48:39 +0200

Hi,

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

> 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