Re: [TLS] draft-shore-tls-dnssec-chain-extension-00

[Viktor Dukhovni <[e-mail]>]

On Tue, Jun 30, 2015 at 11:33:23PM -0400, Shumon Huque wrote:

> > Having browsers have some kind of "validate this chain of DNS records
> > that is asumed to be in some validation order" seems awfully specific
> > code that is "just not DNS enough" to cause problems. I'd rather see
> > the data fed into existing real dns validation libraries.
> 
> 
> Me too. But I think there are some folks who want to implement the
> validation themselves in the application, so the draft is trying to cater
> to both camps.

Notice that Paul said "libraries" not "servers".  So the validation
would still be "in application", but ideally with well tested DNS
code, maintained by experts.  This is a difficult enough bunch of
logic to get right, so making the input as DNS-library friendly as
possible is a worthwhile goal.  The code could also be in a TLS
toolkit used by the application, with the TLS toolkit using a
suitably robust DNS library, or rolling its own validator logic.

Separately, Shumon's mention of CNAME/DNAME raises a critical
complication.  A single chain from a TLSA RRset to the root will
often be insufficient.

Instead, there would need to be in various cases:

    * A validated chain of CNAMEs (possibly synthesized via validated
      DNAME RRs) leading from the client's requested SNI name to
      a final TLSA base domain.  (0 or more CNAME/DNAME indirection
      records and all the DNSKEY/DS/RRSIG records to validate
      these).

    * A validated chain of CNAMES from _port._proto.<base-domain> to
      an actual validated TLSA RRset (and ...).

    * The final TLSA RRset with all the requisite validation records.

    * Also a potential change in the client's notion of the reference
      identifier to match in certificates, to the final TLSA base domain.

While still feasible, this makes locating and processing all
requisite records significantly more complex.  Servers and clients
will need very carefully designed and implemented libraries to
collect and process this data.  Caching at the server end is likely
unavoidable, while the client likely also needs a cache to keep
the handshake overhead more modest on average.

-- 
	Viktor.