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

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 30 Jul 2010 17:20:23 -0500 (GMT-05:00)

Phillip, and all,

  Well made all be it rehashed argument for you IMPO
exactly correct conclusion.

  Single roots of trust that are not of our own choosing
in reality do not exist and are at least inherently insecure
for obvious and varied reasons.  This is, and has been a argument
as well as consideration I have been making for several years now
that has been in the past by a non-accepting cadre of my fellow
IT security professionals.  But now there seems to be a resurgence
and recognition of those years ago given arguments and reasons
which I believe is mostly 'rooted' < no pun intended > in recent
huge breach events from significant presences of which we all
know whom of which I speak, and were long ago predicted by myself
and a few of my fellow IT security professionals at that time.

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Jul 30, 2010 4:08 PM
>To: Nicholas Weaver <[email-masked]>
>Cc: namedroppers <[email-masked]>
>Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications
>
>Folks who have actual security concerns may not be satisfied with a
>model that only provides one root of trust.
>
>That is why there is a requirement for guidance to app writers.
>
>Since I am an employee of a CA, I am not going to comment on the issue
>of pricing except to point out that the assumption this is a
>competitive threat is misguided and creates needless antagonism.
>
>
>At the moment we have a world where only a tiny proportion of Internet
>traffic uses encryption but Third Party issued certificates are used
>for the vast majority of those transactions. Let us imagine that we
>have a world where it becomes really easy to use cryptography and
>cryptography is now used for the vast majority of Internet
>transactions and Third Party Issued certs are only required for a
>minority of purposes. The number of Third Party issued certs would
>likely be considerably higher in the second case than the first even
>so.
>
>
>In my view of PKI security, the only case where a single root of trust
>is acceptable is when I choose the root.
>
>On Fri, Jul 30, 2010 at 1:09 PM, Nicholas Weaver
><[email-masked]> wrote:
>>
>> On Jul 30, 2010, at 9:16 AM, Phillip Hallam-Baker wrote:
>>
>>> One issue missing from the charter is the question of use of DNSSEC in
>>> applications. I think that this is an area that has to be looked at
>>> very carefully, even if the result is an RFC that says 'bad idea'.
>>
>> Actually, its the exact opposite, its not just a brilliant idea, but the only real use:
>>
>> DNSSEC for securing name->address mappings is worse than useless: its actually dangerous to network stability (I'll spare everyone a repeat of my long rant on the subject).
>>
>>
>> The real use for DNSSEC is for DNSSEC-aware applications to obtain through the DNSSEC "PKI" a name->(key material/fingerprint/certificate) mapping which has two substantially better properties than ALL other widely deployed PKIs:
>>
>> 1:  There exists only a single path of trust that can produce a compromised certificate (Contrast this with SSL where there are 66! certificates in Firefox, ALL of which are equally trusted!).  This is a huge issue when SSL sniffers that rely on a cooperative CA are commercially available.
>>
>> 2:  All these PKIs overcharge for wildcard certificates.  EG, even GoDaddy, king of undercut, cut rate pricing, charges $200 for a wildcard certificate for a domain!  DNSSEC is designed to give wildcard certificates, so DNSSEC eliminates a huge amount of price gouging on the part of PKI vendors.  Not to mention, by being wildcard certificates, this makes multihosting cryptographic services much easier.
>>
>>
>>
>> This is, in the end, the beauty of DNSSEC: it is a cheaper to use (free wildcarding) AND more secure (only one path of trust rather than dozens/hundreds) PKI when compared with the alternatives,
>>
>>> In particular, now that we can start to assume that there is going to
>>> be a DNSSEC capability we can think about moving network configuration
>>> data out into the DNS as a matter of course.
>>>
>>> I would like to see documents of the type 'how to easily and securely
>>> hook up a mail client to a server by means of DNSSEC secured RRs'.
>>> Part of that effort may be something that the application concerned
>>> has to deal with, but I see a need for additional DNS RRs and I would
>>> like the approach taken by email and the web and jabber to be
>>> relatively consistent.
>>
>> RRSET for (self-signed, PKI'ed, either one) X509 certs secured by the DNSSEC ZSK.
>>
>> Thus a DNSSEC-unaware application can fetch the X509 cert and treat it like any other cert, but a DNSSEC-aware and validating application can not only fetch but fully validate the signature chain.
>>
>>
>
>
>
>-- 
>Website: http://hallambaker.com/
>

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k 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: Fri, 30 Jul 2010 17:42:51 -0500 (GMT-05:00)

Paul and all,

  Sorry I disagree with the conclusion of you argument.
One doesn't need to trust all 66 of them in you example
argument.  One only needs to be able to trust some
subset of those 66, or perhaps only one of those 66
if all others fail whatever criterian tests one has for
any of same.

  However relying only on one that is not of your choosing
inhearently provides for the opertunity for various forms
of corruption by any number of parties no one else may know
about until after the fact, which is sometimes of not usually 
the case.

-----Original Message-----
>From: Paul Wouters <[email-masked]>
>Sent: Jul 30, 2010 5:23 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: Nicholas Weaver <[email-masked]>, namedroppers <[email-masked]>
>On Fri, 30 Jul 2010, Phillip Hallam-Baker wrote:
>
>This implies of the 66 roots in the browser, you only need to trust one. That's
>not the case - you need to trust 66 of them. That does not scale. The federated
>DNS approach has a big advantadge. Trust moves from larger to smaller groups,
>you can override it at any point for your personal 1 trust anchor, and you are
>guaranteed the entire world sees the same view as you, making it extremely likely
>abuse or compromise is found really quickly.
>
>Paul
>

Regards,

Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 30 Jul 2010 17:47:40 -0500 (GMT-05:00)

Paul and all,

  Both approaches have merit.  But I prefer Nick's better
because it lends itself better to a layered approach to 
overall enterprise security.  

-----Original Message-----
>Sent: Jul 30, 2010 5:18 PM
>Cc: Phillip Hallam-Baker <[email-masked]>, namedroppers <[email-masked]>
>On Fri, 30 Jul 2010, Nicholas Weaver wrote:
>
>I'd rather see you extract the public key from the cert and put a hash
>of that in DNS. If you then add a new EDNS option for "give me a hash of
>pubkey of https service if you have one", we can integrate HTTPS much
>better, and without stuffing all these uselesss X.509 fields into the
>DNS - avoiding larger packets full of
>cruft.
>
>Paul
>
>

Regards,

Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 31 Jul 2010 16:01:58 -0500 (GMT-05:00)

Bill and all,

  Your last point is a good one and I for one agree
that such is, or may be a problem in some if not many
instances.

-----Original Message-----
>From: [email-masked]
>Sent: Jul 30, 2010 9:21 PM
>On Fri, Jul 30, 2010 at 10:09:55AM -0700, Nicholas Weaver wrote:
>> 
>	this is patently false.  there are at least -two- trust paths. the place
>	where they converge is only at the root.
>
>	the one thing that worries me is that trust is not transitive, the DNS admin
>	is generally not the sysadmin of the node in question and so syncronization
>	between the sysadmin and the DNS admin(s) is an exploitable channel.
>
>--bill
>

Regards,

Jeffrey A. Williams