Re: [TLS] draft-shore-tks-dnssec-chains-extension

[Viktor Dukhovni <[e-mail]>]

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.

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 do strongly prefer the binary blob to be in raw dns format. That
> will make parsing easier with existing code, and over time we will
> not run into issues where dns libraries support newer algorithms
> but this specific dnssec parsing code isn't updated.

I'm not sure what "algorithms" you have in mind?  We should perhaps
allow (even encourage) "compression" to reduce the payload size,
this would require the client to "uncompress" (canonicalize) all
the RRs before checking the RRsigs.  Once canonicalized, DNSSEC
signature checks don't care how the canonical forms of each RRset
were constructed, and the wire form (which is not canonical) is
not more compatible with new signature algorithms than any other
representation.

> 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.

-- 
	Viktor.