On Fri, Jun 26, 2015 at 12:50:54AM +0200, Patrick Ben Koetter wrote:
> # Experience
>
> Barry also suggested I summarize our experience with DANE. Here's a list
> of things we've learned or I believe to have understood (sudden moments
> of clarity are a great thing [tm]):
Thanks.
My experience behind is based primarily on tracking the implementations
and deployments of others, rather than doing my own.
The main take-away for me has been:
Individuals deploying DANE in small scale personal domains
to make a statement of support for on-line privacy, often do
so as a point-in-time exercise.
A year or more later, when the decide to replace their
certificate and/or private key, they often neglect to update
their TLSA RRset, and end-up with TLSA records that don't
match reality, until my monitoring catches up with them and
they fix the problem.
We need to find ways to embed reminders to do key rotation
right into configuration files, README files in directories
with keys and certificates, perhaps even the certificates
themselves. Also into any monitoring tools that report
"imminent" certificate "expiration", which need to remind
users about any associated TLSA RRs if any also exist. This
needs to be emphasized in product documentation, we must
shout it from the rooftops!
Server operators really need to take to heart the content of
section 8 of the "dane-ops" draft.
Substantially fewer early adopters had outright DNSSEC zone signature
problems, than failures to update TLSA records. I think this is
in part due to the fact that zone re-signing is easily automated,
and failures are immediately felt, so are remediated quickly.
So while DNSSEC is difficult to deploy, most domains continue to
work reliably after initial deployment.
There are some domains that have *only* deployed DNSSEC (e.g. much
of the ".gov" TLD), and have not yet done anything with DANE, but
which have broken firewalls that block requests for "unexpected" DNS
query RRtypes.
https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07
This causes some grief for DANE early adopters, but fortunately
the domains with working DANE already substantially (more than 10:1)
outnumber the domains with broken nameservers. Just a handful of
sites fixing nameservers or firewalls would lower this number by
another factor of 10. This is IMHO not a long-term concern.
Finally, some domains publish TLSA RRs, but install software that
selectively enables TLS support only for clients that pass some
sort of "good behaviour" test (e.g. SMTP grey-listing). This creates
a catch-22, in which DANE clients can never pass the test because
the server never offers TLS, and so always fails authentication.
This is rather rare, and should not be a significant problem in
for most domains.
I am hoping that once one or more of the largest domains enables
DANE for SMTP, there will be much greater visibility of problems
for any administrator who misconfigures his system, resulting in
immediately noticeable mail delay. This should act to substantially
reduce the number of sites having problems (for any length of time),
and I hope administrators will learn to avoid the above and similar
problems.
On the software implementation side, I continue to see flawed
attempts at DANE verification code. Generally, usage DANE-EE(3)
is implemented correctly, while the verification logic for usage
DANE-TA(2), PKIX-TA(0) and PKIX-EE(1) is often rather insufficient
to the task.
Implementors often don't take the time to understand that the "heap"
of wire certificates from the remote peer don't necessarily form
any sort of "chain", or even if a chain can be formed from the leaf
to some ultimate issuer, that chain may well not include any of
the certificates in the peer's "heap" that matched the TLSA RRset.
Finding some certificate on the wire that matches the TLSA
RRset is far from sufficient unless that is the leaf certificate,
and the usage is DANE-EE(3).
Then we have the usual failures to perform hostname checks (all
usages other than DANE-EE(3)), or to support the additional
reference identifiers required in the SMTP and SRV drafts.
Bottom line, without a major investment of time, and great
care, even reasonably experienced programmers are only able to
write correct validation for DANE-EE(3) and no other usages.
Had the DANE WG in crafting RFC 6698 given much more weight to
programmer fallibility, we might have had just usage DANE-EE(3) to
contend with (and it likely would have been good enough for everyone,
despite the fact that DANE-TA(2) has some operational advantages
for large deployments). Reaching rough consensus on such a
"radically" minimal model was likely not possible, but we're likely
to deal with security advisories for DANE-enabled products that
are due to the complexity of the other options.
As of today, I am tracking 1450 domains with DANE TLSA records
published for at least one of the best preference MX hosts, Most
have all MX hosts covered by TLSA RRs.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
