On Fri, Nov 07, 2014 at 07:58:03AM +0100, DTNX Postmaster wrote:
> Anyway, do you have an example of a legitimate need for SNI, one that
> cannot be addressed by using a multi-domain certificate, adding extra
> IP addresses and splitting it that way, or using Victor's port example?
I think the time to add SNI support will be either in next year's
snapshots, or the year after. By that point OpenSSL should have
well behaved (in all the gory details) SNI support, and maybe even
a more sensible API for using it.
For now, with thin client support and other drawbacks, there has
been little incentive to spend precious cycles on that.
In the mean time, a public service announcement from your DANE
evangelist:
1. DNSSEC and DANE are not fashion statements, do not sign
your zone or publish TLSA RRs if you don't know how to keep
the signed data fresh and correct on an ongoing basis.
Only do this if you understand the role of registrar DS
records, the need to automate zone resigning, how to
coordinate key rotation with TLSA record updates, ...
2. With the above warning, consider first enabling outbound
DANE validation, this is much more difficult to mess up.
The more people use validating resolvers and check DANE
TLSA records, the faster domains that publish bad data
know they've messed up and fix it on their end.
3. If you're skilled with power tools, by all means, sign your
zone and publish TLSA RRs. I've curated over 300 domains
that have done so, and likely many more have managed to do
likewise, but stay off my radar. MAKE SURE you have a
working postmaster mailbox, some day you'll need it.
Content filter it if you must, but do read your postmaster
mail. When some receiver's DANE records are busted, sending
notices to some privacy-protect whois address is too much
work.
4. The reason for this public announcement is that a small,
but not insignificant fraction of the early adopters (small
hobbyist domains by and large, with a few notable mid-size
exceptions) are forgetting to re-sign their zones, or update
TLSA records when rotating keys or are confused about the
difference between "DANE-EE(3) Cert(0) SHA2-256(1)" TLSA
records, and "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA records.
The published digest MUST match the corresponding object
(certificate or just the public key).
So if you're still learning the ropes, wait. We'll soon have more
test sites, to verify that you've not messed up, better documentation
and tutorials, better automated key management in name-servers,
easier updates of registrar DS records, ...
If you're not scared off by the warnings by all means proceed, but
DANE will work much better for both sending and receiving systems
if mistakes are quite rare.
--
Viktor.
