On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:
>
> > I think the server should stick to one chain, from the root to itself,
> > so it does not have to deal with variable chain blobs per client.
> > That will allow server code to stick to something like hourly
> > regenerating the blob for use with all clients.
>
> >From the root to its own TLSA RRset, however, this can be complicated
> in the presence of CNAMEs:
>
> www.example.com. IN CNAME cdn.example.net.
> cdn.example.net. IN A 192.0.2.1
> _443._tcp.cdn.example.net. IN CNAME _dane.example.net.
> _dane.example.net. IN TLSA 2 0 1 <trust-anchor-digest>
>
> In this example, three leaf RRsets need to be verified back to the
> root (with notable overlaps in the chains):
>
> www.example.com. IN CNAME <RDATA>
> _443._tcp.cdn.example.net. IN CNAME <RDATA>
> _dane.example.net. IN TLSA <RDATA>
>
> How should these be organized? It seems to me that the immediate
> answer that gets the client going in the right direction is the
> first CNAME, which enables to construct the TLSA base domain,
> and then to follow the second CNAME to the ultimate TLSA RRset.
>
There are a number of possibilities here, including more complicated data
structures. But I think we can use the current linear chain structure and
have it composed of multiple sequences corresponding to intersecting
branches of the DNS tree.
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>
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>
Should everything other than the first CNAME be in additional
> records? Should all the above (with their RRSIGs) be in the answer
> section, with the union of the supporting DNSKEY/RRSIG/DS records
> as additional?
>
> I tried to ask a related question during the meeting, but bandwidth
> to explain the context was limited: Should proofs of non-delegation
> be included, to keep gTLDs and ccTLDs honest for some future CT for
> DNS? Specifically, suppose you see:
>
> _443._tcp.www.example.com. IN TLSA <rrdata>
>
> with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
> records that demonstrate that "example.com" (and www.example.com)
> are not delegated? (Such records might then be subject to "gossip"
> or related "transparency" counter-measures).
>
I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more
before considering DNSSEC key transparency issues.
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.
> > As for ekr's question on why not stuff this inside X.509, that would not
> > be compatible with tls raw pulic keys that only contain a SBKI, and drag
> > back into the protocol more ASN.1 parsing and containers.
>
> 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.
Shumon Huque
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
