> At least 3 host names in the list of DANE test sites do not use DNSSEC.
> http://www.internetsociety.org/deploy360/resources/dane-test-sites/
Then it's a good thing that we're testing that case, isn't it? :-)
DANE implementations should refuse to connect to those test sites,
which don't have DNSSEC signatures all the way back to the root key.
(The fact that DANE should fail with them should be mentioned in that
page tho.)
> >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same as
> >> 3. The difference is that if my certificate is signed by a CA I use 1,
>
> Well, my point is that they transfer exactly the same data. 0 transfers
> an end-entity certificate and so does 2. They differ, as you say, on
> what the receiving party does on that data. Why bother? How would a
> server operator ever know what the receiving party will do on the data?
This is a protocol. It defines what both parties do -- not just
one party. Two parties interoperate in a protocol when BOTH implement
it correctly.
The whole reason for the "duplication" in certificate usages is to
protect the business models of the CA operators. For 98% of web
sites, there is no real need for usage 0 or 1 or 2. Just use 3 and
the DNS will let your TLS application know that it can trust the
public key that the TLS server provides. Indeed, the CA companies
tried to kill off usage 3 -- and succeeded to the extent that you have
to read between the lines of a complicated RFC to figure out that you
don't need the CAs anymore.
You can continue to pay a CA for your TLS server's cert, so that
clients who don't implement DANE can still access your server with the
same security that you and they had last year. But any client that
does implement DANE will just use your "usage 3" TLSA record, will
ignore the CAs, and will have higher security.
But the CA companies can say, "Use DANE with our certificates" and
still sucker a bunch of businesses into paying them $$$$$ that they
don't need to pay, for security that isn't really there. And indeed
DANE does provide a way to improve the security of the CA model, by
limiting the number of CAs who can betray you, from hundreds down to
one. Of course, if you use DANE with usage model 3, NONE of the CAs
can betray you to a DANE client -- but they won't tell you that.
By the way, you're confused about which cert usage numbers do what.
The TLS server always sends the client a chain of certs, containing at
least one cert. The client only has to pay attention to the first of
those, which is the "end-entity" cert for this TLS server. The rest
are "hints" about how the client might determine whether to trust that
"end-entity" (TLS server's) cert. Unfortunately the process that the
client goes through is undocumented and unstandardized and will remain
so for business reasons (different clients do it differently and none
of them wants to be declared non-compliant). They all rely on "trust
anchors" which are keys that are inherently trusted by that particular
client, usually because those keys were installed automatically along
with its OS or along with its browser. DANE provides three ways to
*modify* that undocumented process, and one way to bypass it
completely:
0 = I'm telling you one of the PKIX CA certs (or its key)
1 = I'm telling you the PKIX end-endity cert (or its key)
2 = I'm giving you a PKIX cert that provides a new trust anchor (or
a key of one that the server sent in its chain)
3 = I'm telling you the non-PKIX key or cert of this TLS server.
3 is the complete bypass of the PKIX hierarchy of certs. 0,1,2 all
use the PKIX certs and require that the TLS connection fail if the
undocumented PKIX client processing says "insecure". They also require
that the TLS connection fail if PKIX says "secure" but its ultimate
trust-chain doesn't match any cert or key that DANE provides. (That's
DANE protecting you from corrupt CAs.)
Normally, usage 2 does NOT use an end-entity cert. There's a way to
bastardize usage 2 by providing the end-entity cert or key as the
"trust anchor", but that's just a slow way to do usage 3, so there's
no point to it. What it's really for is to provide a CA "trust
anchor" certificate that you don't expect clients to already trust.
For example, IBM might run its own CA for all its internal machines,
and could provide this CA's trust anchor cert in its internal DNS with
DANE usage 2, rather than having to reconfigure every machine in its
network to add a trust anchor manually.
John Gilmore
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
