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

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

Michael and all,

  Nice outline.  What still bothers me is all this is still tied
to trust anchors.  How do we or anyone know or do about a trust
anchor that has been corrupted or otherwise breached?  It is likely
that the knowing of same will be delayed by some time factor and the
potential damage assessment may take even longer.  So there is a real
likelihood of potential harm here...

  Secondly, the same condition could/will apply to CA's Cert Database
with similar results. As some of us already know and has been detected,
reported and documented a few of the larger and well known CA's have had
their Cert databases breached leaving Cert holders from those CA's in
a very uncomfortable if not dangerous position on a number of levels.

-----Original Message-----
>From: Michael StJohns <[email-masked]>
>Sent: Oct 4, 2010 1:30 PM
>To: [email-masked], [email-masked], [email-masked], [email-masked]
>Cc: [email-masked], [email-masked], [email-masked], [email-masked]
>Subject: Re: [TLS] [pkix]   Cert Enumeration and Key Assurance With  DNSSEC
>
>Hi -
>
>DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both?
>
>
>DNSSEC provides a "secure" association FROM the name TO the IP address.  But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.  Also, DNSSEC doesn't protect from IP hijacking (re-routing).
>
>PKIX provides a "secure" association TO/FROM "a" name to a public key.  The host owner holds the private key and can prove "ownership" of the related public key.  But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner.
>
>
>What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner?  A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC?
>
>
>The path goes something like:
>
>1) Use DNS and DNSSEC to find the host (or even just DNS)
>2) Use TLS to grab the certificate
>3) Verify the certificate using the PKIX path to a trust anchor
>4) Verify the host knows the private key related to the host certificate
>5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK)
>6) Verify the name offered in the certificate matches the DNS name looked up.
>
>You've verified that:
>a) The zone owner has assigned the name to the owner of the cert's private key
>b) The host owner has agreed the host has the DNS name.
>c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe).
>
>The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue.
>
>A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue.  
>
>Mike
>
>
>
>_______________________________________________
>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: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 5 Oct 2010 12:49:19 -0500 (GMT-05:00)

Ralph and all,

-----Original Message-----
>From: Ralph Holz <[email-masked]>
>Sent: Oct 5, 2010 11:48 AM
>To: 
>Cc: [email-masked]
>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.

We agree here.
>
>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.

Ok I understand your point I think.  The bigger problem is, or seems to
be the trust model itself, which I have concerns about and made those
very clear on more than one occasion.  
>
>> 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.

Maybe not, but given the state of CA's and now Trust anchors to a degree,
I don't see how logically and positively one can pin any Cert without
some possibility of miss-pinning same depending on of course what the
method one is pinning the Cert too exactly for assurance reasons.  I
can think and/or know of a few Trust Anchors I would NEVER try to pin
any cert too, and I can also think of several issuing and USG certified
CA's I would not, and do not trust regardless of which Anchor they may be
accurately/effectively pinned too.
>-- 
>Best regards,
>Ralph

Regards,
Jeffrey A. Williams

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Oct 2010 12:03:06 -0700

As much as I hate to spam multiple lists, I need to correct a technical error. And, really, this discussion should be happening on the keyassure mailing list.

At 12:56 PM -0400 10/5/10, Phillip Hallam-Baker wrote:
>But the design approach taken in the Hoffman et. al. proposal is that publication of a DNSSEC assurance for a cert disables verification on the PKIX chain unless the 'preferences' flag is set.

That statement was untrue in draft-hoffman-keys-linkage-from-dns-02, and the flag was removed in -03.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Oct 2010 04:23:25 +1300

>DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is

Maybe the right answer is a paddling pool full of jello and Marquess of
Queensberry rules?

Peter (just adding to the available options a bit).

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 11 Oct 2010 14:31:35 -0500 (GMT-05:00)

Henry and all,

-----Original Message-----
>From: "Henry B. Hotz" <[email-masked]>
>Sent: Oct 5, 2010 1:32 AM
>To: "[email-masked]" <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Michael StJohns <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>On Oct 4, 2010, at 5:46 PM, Martin Rex wrote:
>
>>> DNSSEC provides a "secure" association FROM the name TO the IP address.
>>> But the DNS domain owner tends not to be the host owner so this asserted
>>> association may not reflect the intent of the host owner.
>>> Also, DNSSEC doesn't protect from IP hijacking (re-routing).
>> 
>> Incorrect characterisation.  DNSSEC provides only for secure distribution
>> of DNS records.  Whether the distributed DNS records are accurate or
>> trustworthy is a completely distinct issue.
>
>
>I think secure distribution of DNS records implies secure distribution of name to IP associations. 

I agree. 
>
>Whether those records are <whatever/> depends on the practices of the domain administrator.  Is a 3rd party CA is more or less (likely to be) trustworthy than the relevant domain administrator?

Good point IMO, and one that seems all to often to be missed or largely ignored for whatever
reason.  My answer to your nicely and simply possed question is that the 3rd party CA is less 
likely to be MORE trustworthy than the relevant domain administrator.  One can never know when
or if ones chosen CA goes rogue or has a corrupted or hacked Cert database.  Same can be said
for Trust Anchors.  However I am sure that many would disagree with my opinion here.  Additionally
similar can be said in respect to the relevant domain administrator.
>
>------------------------------------------------------
>The opinions expressed in this message are mine,
>not those of Caltech, JPL, NASA, or the US Government.
>[email-masked], or [email-masked]
>
>
>

All,

  As predicted some years ago now seems that Libya has taken
upon itself as the host nation of the .ly ccTLD to insure that
domain names registered in their name space are more 'Family
friendly' and in compliance with whatever standard(s) in Lybia
that would determine same...???  I wonder if such standards are
documented and articulated fully accordingly.
See:http://www.bbc.co.uk/news/technology-11484751

  Note: I wonder how many requests from various countries to
hosting services or Registrars for .com, .net, .org, .info, .mobi,
and or any other name space TLD, generic or otherwise, will be
recieving even more to a flood of requests/demands for DMCA takedown's
due to 'questionable content or use'?  My guess is the number will
be growing rather rapidly as will similar for IPv4 and IPv6 addresses
for similar reasons.  Of course this activity should give civil liberty
lawyers a boon in new business and be filling up the court dockets in 
some countries with such cases for years to come.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 18 Oct 2010 16:26:05 -0500 (GMT-05:00)

Martin and all,

  Execellent point!

-----Original Message-----
>From: Martin Rex <[email-masked]>
>Sent: Oct 18, 2010 1:28 PM
>To: Bruno Harbulot <[email-masked]>
>Cc: [email-masked]
>EV vs. DV is primarily about "risk management", based on the
>flawed assumption that "green-bar" vs. blue-bar/white-bar 
>would affect user behaviour.
>
>Look at the real world:
>signin.ebay.<country> uses an EV-Cert, probably because ebay may
>have to pay for damages if someone steals user account credentials
>and abuses them.
>
>payments.ebay.<country> uses a DV-Cert, because the user bears all
>risks from his payment data getting leaked.
>
>
>-Martin
>
>
>
>Bruno Harbulot wrote:
>> 
>> On 04/10/10 21:04, Phillip Hallam-Baker wrote:
>> >
>> > For the past five years, CA certificates have been divided into Domain
>> > Validated and Extended Validated. As some of you know, I instigated the
>> > process that led to the creation of EV certs because I was very worried
>> > about the low quality of many DV certificates.
>> >
>> > Some DV certificates are of very low quality. Which is why I would like
>> > to see the padlock icon phased out entirely. Why does the user need to
>> > know if encryption is being used at all?
>> 
>> I'm still not convinced about the greatness of EV certificates.
>> 
>> Why should an organization that wants to deploy its own PKI have to 
>> depend on one of the big players who've managed to get their signature 
>> hard-coded into browsers?
>> 
>> How beneficial are EV certs for the end-users? Green-bar secure v.s. 
>> Blue-bar insecure (or less secure) really is a confusing 
>> over-simplification.
>> 
>> A DV certs bind a cert to a domain, whereas an EV cert bind a cert to a 
>> company name. However, some companies use domain names that have nothing 
>> to do with their company name, and which could look like competitors 
>> instead: http://www.ietf.org/mail-archive/web/tls/current/msg06528.html

Regards,
Jeffrey A. Williams