Subject: [dane] while we're waiting for DANE deployment...

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 Jun 2013 20:02:45 -0600

DANE is awesome and will solve many practical challenges with the
existing PKI (e.g., the inability to securely offer proper
certificates for hosted domains in multi-tenanted environments).

Unfortunately, DANE won't be widely deployed anytime soon. (As one
example, we're still struggling with the lack of DNS SRV support among
domain registrars for certain major TLDs, let alone DNSSEC support.)

Thus we need something that solves some of the same problems as DANE,
but that can be deployed much more quickly.

Matt Miller and I have been working on this problem for some time in
the XMPP community, and we have recently generalized the approach
we've defined, called "PKIX Over Secure HTTP" or "POSH":

https://datatracker.ietf.org/doc/draft-miller-posh/

As the abstract says:

   This document defines two methods that make it easier to deploy
   certificates for proper server identity checking in application
   protocols.  The first method enables a TLS client to obtain a TLS
   server's end-entity certificate over secure HTTP as an alternative to
   standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based
   Authentication of Named Entities (DANE).  The second method enables a
   source domain to securely delegate an application to a derived domain
   using HTTPS redirects.

Feedback from folks in the DANE community is very much welcome on the
[email-masked] list:

https://www.ietf.org/mailman/listinfo/posh

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Jun 2013 14:23:31 +0000

> certificates for hosted domains in multi-tenanted environments).

Isn't this *supposed* to be solved via SNI?  (I personally don't
believe SNI scales, but I'm willing to go along with the idea for
argument's sake now and then).

Is it no longer controversial to say that SNI does not solve the
multi-tenant problem?  If so, then I'd like to more strongly
emphasise my comments on DANE and CNAMEs.  If DANE clients chase
CNAME RRs (while keeping track of DNSSEC validation at each step),
then multi-tenant deployments can avoid SNI depedence, as the TLSA
RRs would only need to be published in one place by the service
operator.  Otherwise, it is not clear how DANE addresses the
multi-tenant issue.

> domain registrars for certain major TLDs, let alone DNSSEC support.)

Is the main obstacle in your view lack registrar infrastructure to
support customer DNSSEC deployment, or lack of tools for customers
to manage DNSSEC zone signing?

>    source domain to securely delegate an application to a derived domain

This requires TLS clients to also also implement HTTPS, and to able
to do PKIX validation of HTTPS peers.  Plus additional latency to
fetch the certs via HTTPS with no local cache (as with DNS).  This
certainly looks unappealing from an SMTP perspective.

> https://www.ietf.org/mailman/listinfo/posh

I'll take a closer look when I get a chance, but I am skeptical.

New standards take a long time from inception to wide adoption.
Software released today takes ~2-5 years to be included by O/S
distributions (if bundled as with MTAs) or upgraded by a majority
of the user base.  Browsers with their independent distribution
channels are the exception, not the rule.  So I think that deployment
barriers today should not overly prejudice architectural decisions
for software that will only become mainstream in ~5 years.

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Jun 2013 09:39:06 -0600

[ + [email-masked] - I will drop [email-masked] if this thread continues ]

On 6/21/13 8:23 AM, Viktor Dukhovni wrote:
>> DANE is awesome and will solve many practical challenges with
>> the existing PKI (e.g., the inability to securely offer proper 

The core problem in the PKI context is that BigCompany.com isn't going
to hand over its private keys to ConvenientHostingService.com, and the
hosting company doesn't want those keys anyway for liability purposes.

> operator.  Otherwise, it is not clear how DANE addresses the 

With POSH we are trying to find an interim solution to PKI issues. I
*think* (although I have not yet proved it out) that DANE solves those
problems, too. But the PKI problems are pressing enough that we need
to solve them as soon as possible.

>> Unfortunately, DANE won't be widely deployed anytime soon. (As
>> one example, we're still struggling with the lack of DNS SRV
>> support among domain registrars for certain major TLDs, let alone
>> DNSSEC support.)
> 

IMHO, probably both. But I will ask some folks on the operational side
to find out more.

>> protocols.  The first method enables a TLS client to obtain a
>> TLS server's end-entity certificate over secure HTTP as an
>> alternative to standard Public Key Infrastructure using X.509
>> (PKIX) and DNS-Based Authentication of Named Entities (DANE).
>> The second method enables a source domain to securely delegate an
>> application to a derived domain using HTTPS redirects.
> 
> This requires TLS clients to also also implement HTTPS, and to
> able to do PKIX validation of HTTPS peers.

Yes, but we figure that such code is very widely available.

> Plus additional latency to fetch the certs via HTTPS with no local
> cache (as with DNS).  This certainly looks unappealing from an SMTP
> perspective.

A happy eyeballs approach should help with latency.

>> Feedback from folks in the DANE community is very much welcome on
>> the [email-masked] list:
>> 

Your skepticism is appreciated.

> channels are the exception, not the rule.  So I think that
> deployment barriers today should not overly prejudice architectural
> decisions for software that will only become mainstream in ~5
> years.

That is a valid point, and one that we'll need to consider at the BoF
in Berlin.

Pete

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Guido Witmond <[email-masked]>
Date: Fri, 21 Jun 2013 18:50:56 +0200

> That is a valid point, and one that we'll need to consider at the BoF

That's a good argument to work on browser plugins. Like the ridiculed
Extended DNSSEC validator. Or the next version of CZ.nic's original plugin.

Even if the only purpose of these tools is to raise awareness about
DNSSEC/DANE, I believe it's worth it.

My authentication protocol relies on DANE, so I made it into a browser
proxy. [1]

Regards, Guido.

[1] http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html