On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
> For the following hypothetical example:
>
> _443._tcp.www.example.com. IN CNAME ca.example.net.
> ca.example.net. IN TLSA 2 0 1 <cadata_blob>
This is simpler than the general case, everything is still "linear",
because there's only a CNAME chain leading to the TLSA RRset.
More generally, there's also a CNAME chain leading to the TLSA base
domain:
www.example.com. IN CNAME www.example.com.cdn.example.net.
www.example.com.cdn.example.net IN CNAME node1.example.net.
node1.example.net. IN A 192.0.2.1
_443._tcp.node1.example.net. IN CNAME ca.example.net.
ca.example.net IN TLSA 2 0 1 <cadata_blob>
Here, we have CNAME (perhaps via a DNAME) indirection from the SNI
name (www.example.com) to the actual TLSA base domain (node1.example.net).
And then more CNAME records from there to the CDN provider's TLSA
RRset.
This is no longer the DNS response to a single query (iterative
resolvers generally chase CNAMEs), since one first CNAME expands
the original target hostname to obtain the TLSA base domain (provided
the CNAME chain is validated end-to-end) and then CNAME expands
the _443._tcp. prefixed base domain to find the TLSA RRset.
> the getdns library's validation chain function currently returns (RRSIGs
> omitted for brevity):
>
> _443._tcp.www.example.com. CNAME
> ca.example.net. TLSA <set>
>
> example.com. DNSKEY <set>
> example.com. DS <set>
> com. DNSKEY <set>
> com. DS <set>
> . DNSKEY
> example.net. DNSKEY <set>
> example.net. DS <set>
> net. DNSKEY <set>
> net. DS <set>
The getdns library is unlikely to handle the fully general case,
because first the TLSA base domain has to be found.
> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the future incorporate SCT RRs in
> the chain. However do we really need to? The TLS server is the one doing
> the DNS queries, so it could perform the SCT checks against the logs it
> trusts, while querying the chain records, and then build the validated
> chain. I'm not sure there is a need for the TLS client to additionally do
> these log checks, so it doesn't need to have that info delivered in the
> chain.
The TLS server is not trusted, the whole point is detect malfeasance,
where the DNS operator and TLS server conspire to lie (to selected
clients).
> > This really can't go in the certificate, because then certificates
> > would have to be updated as often as RRSIGS are regenerated. That
> > seems exceedingly unlikely to be deployable.
> >
>
> I believe Eric's question was about why this couldn't be done via a new
> 'Certificate Type' (and not about embedding the chain in the X.509 cert). I
> presume the idea being the new certificate type would allow both the
> server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
> be delivered in the server's Certificate Message. I believe the argument
> for doing it via a new TLS extension was that it would allow us to mandate
> the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> Extension.
I see. I think the question of whether "must staple DANE" is
supported or not is quite orthogonal to the question of how DANE
stapled data is encoded.
The disadvantage of this being a new certificate type is that AFAIK
it would then not be orthogonal to the choice between X.509 chains
and raw public keys. We might then have a (small) combinatorial mess:
traditional X.509 chain
X.509 chain with stapled DANE evidence
raw public key
raw public key with stapled DANE evidence
I think the extension is a more logical separation of duties, but
I am willing to hear contrary arguments.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
