Subject: Re: [keyassure] Certification Authority Authorization Draft.

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 24 Oct 2010 15:59:36 -0500 (GMT-05:00)

Paul and all,

-----Original Message-----
>From: Paul Wouters <[email-masked]>
>Sent: Oct 24, 2010 3:44 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Certification Authority Authorization Draft.
>
>On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:
>
>> Assume for a moment that other CAs don't follow our lead and end up mis-issuing against a domain that has a CAA record. What do you
>> think their liability is in that case? They certainly have a major PR issue at that point and their only realistic chance of
>> surviving it without too much damage is going to be to deploy CAA.
>
>Seeing that rapidssl is still very much alive, I think we can safely say PR is not a valid detergend
>against running an uhm, less then optimally secure CA.
>
>> You may also be interested in my DPLS draft: 
>> 
>> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
>
>A quick peek:
>
>    DPLS allows for more efficient secure DNS resolution by enabling a
>    trusted resolver to efficiently authenticate communiction with a
>    client.
>
>I doubt the impact of running DNSSEC on the enduser is that much
>of an impact these days. Especially because of DNS caching. Plus,
>if efficiency is an issue, configuring the enduser to use a trusted
>validating usptream resolver addresses that problem too (except it would
>not have confidentiality, but see below)

  Confidentiality is a significant issue though...
>
>    A secondary advantage of using DPLS is that it enables traffic
>    between the DNS client and resolver to be encrypted, thus reducing
>    exposure to confidentiality attacks.
>
>It might protect last-mile wifi confidentiality attacks, but nothing
>else. Because it is easy to give unique DNS labels to clients for tracking
>purposes, unless hundreds+ clients are all congregating their traffic
>at a common DNS server (something that TOR tries to do)

  If your correct, and I am not sure you are, still confidentiality attacks
are reduced.  That's an improvement.  
>
>
>> A lot of the DNS performance issues go away if the DNS client can ask its resolver 'hey give me all the info I need to do this with
>> that'.
>
>Those can be done using EDNS options as well.
>
>the draft discusses a lot of split DNS setups and required confidentiality, but
>that all boils down to "enterprises need VPN + company DNS server". I am unclear
>how this draft would change that, except adding some new kind of transport layer
>security. If one would design something like that, the very least I would expect
>is a way to return more data to the client in bulk that it will encounter when
>doing more queries anyway. Latency is the performance issue here, not bandwidth
>or CPU usage.
>
>Paul
>Paul
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"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