Subject: [dane] an implementor's comments on DANE

From: "Daniel Piggott" <[email-masked]>
Date: Tue, 9 Oct 2012 20:12:08 +0100

Just stepping back with a commercial third party hat on, can I add a few
questions to this debate. If my understanding of DANE is wrong please let me
know. I am talking here from the SME perspective. What if a business never
handles it's dns but leaves it it's third party IT supplier? What if the
host that controls the domain does not support dnssec currently? What if
websites are sitting on shared virtual boxes and a reseller cannot make
revenue from ssl certificates currently, why would they pursue dane from a
commercial perspective? From an technical and security viewpoint I am
completely sold on DANE but i see the current real world commercial and
technical reality stopping deployment. Daniel  

On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote:

> Your model for why people buy certs is completely wrong.
> 
> The biggest cost in providing SSL certs is training the customer how to
use and deploy them.

I could not have summarized the failure of the CA industry better.

If they had made $5 certs for everyone, we would have never seen the
explosion in people using unvalidatable self-signed certificates.

DANE is indeed a method where obtaining the validation is totally free, and
it does not raise the bar for any non-enterprise that cannot afford a
training budget.

> An SSL cert is a heck of a lot cheaper than a course on PKI.

The fact that one would need a course on PKI to secure one's webserver is a
pretty bad failure of the security industry. We're paying the price now (and
offloading that mostly to the browser vendors to fixup in gui
elements)

> The typical cost of training is $800 per person per day. How many days 
> does it take to know enough crypto for it to be more good than harm?
Probably more than one.

I would cost me $800 to go on a locksmith course for one day, yet I can
easilly buy a lock or cylinder and install it myself. All one needs is
knowledge of a generic tool such as a screw driver.  Another example would
be getting my drivers license, which was far cheaper then the price of my
car.

> DNSSEC deployment is far, far beyond the capabilities of the average
Internet user.

Funny, because these days signing your zone takes 4 commands you don't have
to understand, and one more website visit to get your DS published.

(Willing to give a 5 minute / 2 slide training at ICANN Toronto for less
then $800)

> We both have more than twenty years experience using this stuff and 
> neither of us is signing our emails, that should say something about the
technology.

no it says something about the value of signed emails. A few months ago I
had to use SMIME for the first time ever. With thunderbird this took me
about an hour (most time wasted on a website's interface for validating my
generated cert). It also took one person to spend a little more time, and
writing up a simple step by step manual. It did not take a full day course
(nor knowledge of crypto - anything more then "red wax dot means your
software signed the email"

> Those DNS registrars that you hope are going to provide free crypto to 
> the masses are what CAs call their sales channel. Selling DNS names is 
> not a profitable business, most are sold at a loss in order to acquire
customers that the registrar then monetizes though sales of added value
services, in particular SSL certificates.

If only they had started to give away free SSL certs 10 years ago, and
perhaps by now port 443 would be the default instead of port 80. Forgive me
for not having much sympathy for the CAs economic struggles.

> From a security point of view, I think the whole approach taken in 
> DANE is wrong. It regards security policy statement as commands from the
server to the client rather than as evidence that a client MAY chose to
evaluate in making a security decision.
> 
> No client is going to interpret the DANE MUSTs as mandates no matter 
> how hard people stamp their feet. The client providers refuse to deploy
software that hardfails on OCSP status requests despite a considerably
cleaner path to the client than is available in the DNS world.

That could be said for any MUST in any Security Considerations RFC section.
We set out to write what's best. If local policy dictates shooting yourself
in the foot, we can at best help you not pull the trigger again.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Oct 2012 10:29:24 +1100

In message <006f01cda651$faa63210$eff29630$@[email-masked]>, "Daniel P
iggott" writes:
> handles it's dns but leaves it it's third party IT supplier?

Perfectly do able.  You just pass them the TLSA record to be added
to the zone or you pass them the CERT and tell them to generate the
TLSA record for it.  CERT to TLSA is a mechanical processs.  The
only thing addition is what type of TLSA you are going to generate
and for that you have a choice of 1 of 4 values.  This really is no
different to passing them a A record for a server.

> What if the host that controls the domain does not support dnssec currently?

Ask them to fix their infrastucture or find another company to out
source to.  Nameserver have supported this for 1/2 a decade now.
This is like IPv6.  They just need to get off their butts and do
it.

> What if websites are sitting on shared virtual boxes and a reseller cannot
> make revenue from ssl certificates currently, why would they pursue dane
> from a commercial perspective?

As long as you have a seperate IP addresses (IPv4 and IPv6) for
your virtual machine you just need to add the CERT to the server's
config.  This is no different on the server side to traditional CA
derived CERTs.  If the provider can install a CA derived CERT they
can install a self generated CERT.

> From an technical and security viewpoint I am completely sold on DANE but
> i see the current real world commercial and technical reality stopping
> deployment. Daniel  

This stuff isn't rocket science.  It's the client side that need
extensions to be able to validate.  The server side is "same old
same old".

Mark

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]