On Wed, Jul 29, 2015 at 12:01:28PM -0500, Nico Williams wrote:
> If there's a latency hit, it will be when a sever has both, a long PKIX
> certificate chain and a long DNSSEC/DANE RRset chain to send (since both
> have to be transmitted, and the client may end up having to validate
> both). Operators should avoid this.
This raises an interesting point.
On the one hand the server cannot do much about the length of X.509
certificate chain, it is what it is, and clients may indeed need
to validate "both" (the X.509 chain and its supporting TLSA records
with supporting DNSSEC signatures, keys, ...).
On the other hand, if the TLSA records in question are DANE-TA(2)
or DANE-EE(3), then if the client's extension requesting stapled
TLSA RRs can be interpreted by the server as a reliable signal that
client is doing DANE-TLSA authentication, the server may well be
able to "truncate" its X.509 chain to just those certificates needed
to match the TLSA records.
In particular, with matching DANE-EE(3) TLSA record, the server
might send only the leaf certificate without any intermediate CA
certificates. While with a matching DANE-TA(2) TLSA record, the
server might send a chain that extends only as far as that trust-anchor
certificate and no furhter. If that trust-anchor is a root CA,
this is actually longer than what might have been sent with PKIX
(see the draft-ietf-dane-ops section 5.2). If however, that
trust-anchor is issued by some intermediate CA, then the chain
required to validate ala-DANE is shorter than the PKIX chain (even
sans root CA).
I don't know whether it is appropriate for the extension draft to
discuss such potential (bandwidth) optimizations. The code that
I wrote to validate DANE chains certainly ignores any certificates
beyond the leaf with DANE-EE(3) and beyond the trust-anchor with
DANE-TA(2).
So the optimization opportunity is there, but we'd have to declare
that a client sending the extension effectively commits to using
DANE and forgoes the option of using the full PKIX chain (when a
shorter chain suffices for DANE, i.e. the TLSA RRs contain exclusively
certificate usage DANE-EE/DANE-TA not PKIX-EE/PKIX-TA).
If the optimization is "blessed", then it might even be the case
that at times the leaf certificate plus TLSA RRset with evidence
is shorter than the PKIX chain (if the RRSIGS are EC-based).
This brings us to another point, the server can't know whether its
domain is even DNSSEC-signed in the eyes of the client. The client's
supported DNSSEC signature algorithms are not sent in the client's
extension. Whether the server "optimize" or not, there's not much
point sending a pile of TLSA RRs, and associated RRSIG/DNSKEY/DS
records, if some DS RRset needed to validate the response lists no
algorithms supported by the client.
It might make sense to change the client portion of the extension
to send a list of the client's supported DNSSEC algorithm numbers.
On the other hand, clients that hand-off the validation to the
local resolver (as suggested in recent threads) might not always
know which algorithms are supported by that resolver. That would
have to be client configuration, or something the client can ask
the resolver via an EDNS option of some sort.
So lots of additional fun corner cases to mull over...
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
