On Sun, Jul 19, 2015 at 08:18:18PM +0200, Daniel Kahn Gillmor wrote:
> On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> > 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.
>
> Complicating this further, there could be a chain to an SRV or MX
> record, which then needs to chain to the TLSA, in think (possibly with
> CNAMEs in the mix). This is potentially a pretty long chain. also: how
> does a multi-tenanted server know what SRV or MX chain to include in the
> chain?
My reading of the draft is that it is primary aimed at making DANE
practical for HTTPS, where last-mile considerations on the client
end are a significant part of the adoption barrier.
For HTTP, MX and SRV records are out of scope. Clients that depend
on DNS to the extent of determining the server identity based on
MX or SRV records, already need DNSSEC to avoid MiTM issues, and
at least in the case of SMTP and XMPP are expected to handle DANE
without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
