On Tue, Jul 28, 2015 at 10:43:29PM -0400, Shumon Huque wrote:
> > 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.
> >
>
> Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
> target rather than the owner name. This doesn't seem to be how many early
> HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.
With www.ietf.org, the TLSA record for HTTP was there long before
the DANE ops draft:
www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net.
_443._tcp.www.ietf.org. IN TLSA 3 1 1
0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.1.85
www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.0.85
The DANE ops draft says to look at the end of the CNAME chain (if
secure) first, and if there are no TLSA RRs there, only then stick
with the original name. So sites that do it the old way (as above)
also work. But with the new model cloudflare can provision the "3
1 1" record on their end.
In the case of DANE stapling, the CNAME chasing (or not) is done
by the server, which should ideally know whether it has a TLSA
RRset for the requested SNI domain, or whether it should construct
a CNAME chain starting with that name. The point is that clients
have to be prepared for either outcome.
In essence the server is a DNS proxy for a client that is either
cut-off from DNSSEC, or simply unwilling to pay the latency cost.
The data consumed by the client is the same whether acquired
unilaterally, or via the server.
One could almost imagine a VPN tunnel set up by the client and
server between the DNS caches on either end, except that for multiple
reasons that mental model is rather a crude approximation of the
details. It can however be a useful source of inspiration.
> > 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).
>
> Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
> threat we should take into account.
If and when CT for DNSSEC comes into the picture.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
