On Wed, Oct 01, 2014 at 11:49:48AM +0000, Dan York wrote:
> All the authors of the various drafts on DANE for email (S/MIME
> and OpenPGP) will be there, and we will have discussions on the
> list beforehand. Given this, I for one, hope we can meet and flesh
> out any details left on this topic.
FWIW, I will not be present.
> To Jakob's point, we're going to have a significant number of
> the DANE-related authors and implementors all together at IETF and
> I think a general topic of "What Else Do We Need To Do For DANE
> For Email" could be a good discussion topic.
I am at Frankfurt Airport after a trip to speak about DANE at the
DENIC registrar technical conference.
You may be aware that the most substantial DANE deployments are
for now in Germany, and this is likely to continue through the rest
of 2014, with additional .de deployments, with little progress
elsewhere.
[
Many SMTP domains with TLSA RRs are listed at:
https://www.tlsa.info/statistics/best_results
though this site may not actually be checking that
the servers actually have a matching certificate chain,
rather it looks like it just checks for the presence of
DNSSEC validated TLSA RRs. Ironically, the site's HTTPS
server has an expired stapled OCSP response at the moment.
]
It seems that DNSSEC deployment *is* by far the main obstacle.
Registrars need to support DS RRs and ideally be able to host DNSSEC
domains. Unlike registries looking after one or a handful of
domains, registrars host thousands to millions of domains. One of
the issues raised at the DENIC meeting, is that DNSSEC-capable
nameserver software that scales well to very large zone counts is
by no means abundant. Reportedly only PowerDNS comes close, and
at least some registrars are reluctant to put all the eggs in one
basket and rely on just a single software platform.
So if there is anything that can be done to spur deployment of
additional scalable nameservers, that would be great.
Of course there is also impedance at the consumer end, with a lot
of cable-modems and the like acting as DHCP server + DNS proxy,
but not supporting DNSSEC.
Once DNSSEC is working, the actual DANE deployment is rather a lot
simpler. Just publish some TLSA RRs and implement the right
key-rotation strategy.
For now, only Postfix implements DANE outbound (inbound any MTA
will do, all the DANE-specific code is on the client). Adoption
beyond .de would be greatly advanced if at least one large email
provider published TLSA RRs and/or implemented DANE outbound.
Gmail, Microsoft Office365, Yahoo, AOL, should at least seriously
consider plans towards SMTP with opportunistic DANE TLS. If you can
do anything to prod the right people, that would be great.
Beyond SMTP, it would be great to get some early design work underway
for opportunistic DANE TLS with "h2" (HTTP). I don't see DANE
adoption for HTTPS any time soon (at least not until EV certs go
out of style). DANE can however substantially harden opportunistic
security with HTTP, provided last-mile is under control.
This runs into the "last-mile" problem for DNSSEC. Where are we
with that?
I explained to the DENIC registrars how DANE simplifies virtual
hosting, obviates CRLs and improves effectiveness of "revocation"
(de-publishing bad data from DNS). These are good features for HTTP
to have, but we seem to be no closer to DANE for HTTP.
In the pipeline we have just Exim, some XMPP software, and more
German domains.
> - are there places where it would be helpful if there were
> reference implementations of DANE support? For example, DANE for
> email got a boost when Viktor added it to Postfix. Are there other
> commonly-used open source projects where the addition of DANE
> support would help move deployment along?
Well, Sendmail support would also be nice. But more importantly
some of the closed MTAs would probably be more important:
* Microsoft Exchange
* Ironport, Barracuda and similar appliances
* Gmail, Yahoo, AOL, Office365, ...
Of course having reasonably feature-complete support for DANE in
TLS toolkits would really help. This is why I've joined the OpenSSL
team, with a mission to work on integrated DANE support, once some
of the more urgent priorities in OpenSSL are resolved.
It would be helpful to have sound DANE support in NSS, GnuTLS,
PolarSSL, ... provided these were designed and implemented with
care and are not just incomplete prototypes. In particular, I
don't have the cycles to design-review/code-review all DANE
implementations, but such reviews are likely necessary. Yes,
testing can find many classes of bugs, and a DANE test-suite would
be useful.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
