Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 18 Aug 2010 16:24:49 -0500 (GMT-05:00)

Phillip and all,

  FWIW, I am not sure I would trust a cert signed
by Verisign right now given that recently their 
Cert database was hacked/breached and I have no
independant assurance that Verisign has 'fixed'
that breach adaquately and/or informed 'All' of its
Cert customers accordingly.  None the less, Verisign
produces good Certs, so the question than becomes 
is the user of that Cert now the correct one and
how does anyone know that for sure?

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 18, 2010 2:55 PM
>To: Andrew Sullivan <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>
>On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan <[email-masked]> wrote:
>>>
>>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about
>>> a hostname.  I don't think I know any more than that.  That's pretty
>>> important, but
>>>
>>> 2 - X.509 certificates could tell me a lot more about what I can expect
>>> from the transaction I am starting.  It can deliver a level of assurance
>>> attribute, a policy pointer of some kind that can lead to a complete
>>> disclosure of what this certificate means, and other attributes that
>>> describe what this certificate is supposed to permit or deny.  I don't
>>> think this is available in DNSSEC.  We can argue about the utility of
>>> some of this but that's not the issue.
>>>
>>> Another way of looking at it - this should be up the stack & closer to
>>> the application's viewpoint than DNS is (should be).  So perhaps
>>
>> It seems to me that this distinction is one on which we foundered
>> during the BOF, too.
>>
>> There are two completely different use cases for TLS, and we will get
>> nowhere if we assert that solutions for one are inadequate solutions
>> for the other.
>>
>> The goal in the current keys-linkage draft, as I read it, is simply to
>> gain some assurance that the PKIX cert in question is actually
>> associated with the domain it claims to be.  That is by no means any
>> kind of assurance that (say) the domain is actually operated by the
>> organization one thinks it is (i.e. it doesn't prove that
>> www.mybank.com is actually operated by My Bank, member FDIC).
>
>With DNSSEC alone we have a domain linkage, but no accountability for it.
>
>With DV we have a measure of accountability in that CAs that really
>screw up could in theory be dumped out of the browsers and we have
>defined and audited processes.
>
>With EV we have an industry standard assurance level and audited process.
>
>Now we could have a pointless discussion about whether DV is really
>more secure than DNSSEC, but I think thats pointless as I don't think
>anyone is willing to state that either is a sufficient basis for
>handing over your credit card number or doing banking. And so neither
>should merit a padlock icon.
>
>
>> The first of those is not too far from your (1) (but I think your
>> description doesn't quite capture the power of being able to guarantee
>> you got the right result from the DNS).  The second of these is
>> plainly related to your (2).
>>
>> The fact is that many people think (2) is a waste of time for many
>> purposes: many of the actual CAs simply don't do anything like the job
>> necessary to believe their assertions about identity and so on
>> embodied in the cert.  Therefore, the "utility of some of this" is not
>> the issue directly, but it certainly is a motivating factor in the
>> discussion.  I don't think we can dismiss it.  If the facilities that
>> are supposed to be offered by a technology don't work in practice,
>> then the lack of utility is relevant to rhe duscussion.  (This is not
>> to say the facilities are never useful.  But as general
>> infrastructure, they haven't worked out so well in terms of actually
>> identifying complete strangers to one anhother.)
>
>One big problem here, one that I did insist we deal with in EV was to
>actually show who is providing the certificate to the end user. A
>green bar from a VeriSign or a Comodo may not mean the same to the end
>user as a green bar from Bogocert CA they never heard of before.
>
>The importance of this distinction was just demonstrated in the UAE
>case. Perhaps people are not going to want to trust CAs in certain
>parts of the world for certain purposes. I would not accept code
>signed with a cert from a Nigerian, Sudanese or Russian CA.
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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: "Doreswamy, Rangan" <[email-masked]>
Date: Thu, 19 Aug 2010 11:42:10 -0700

If the reference is to the Code signing certificates that appear to be stolen VeriSign Code Signing certificates I would like to highlight that no VeriSign infrastructure was compromised or any key material was stolen from VeriSign's systems. We became aware of both these attacks when they were reported in the press, and both of the certificates involved are revoked. Each certificate holder was fully cooperative and understanding about the need to revoke the certificates in question. We're looking at potential methods of predicting certificates that may be compromised and therefore used in subsequent attacks and then encouraging preemptive replacement by the holders of those certificates. Microsoft has issued an advisory on the Windows flaw and states it's working on a fix. 

Thanks,
RD
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey A. Williams
Sent: Wednesday, August 18, 2010 2:25 PM
To: Phillip Hallam-Baker; Andrew Sullivan
Cc: [email-masked]; [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

Phillip and all,

-----Original Message-----

Regards,

Jeffrey A. Williams