On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:
> > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > information could be conveyed via the DNS. That way you would not need new
> > holes/fields in the TLS extension. Paul said it doesn't work. But Willem
> > Toorop and I discussed it after the meeting, and think that it does.
>
> I agree that it _could_ be done with a DNS RR. However, that has two
> negative effects: 1) it will bloat the extension's payload more than the
> two bytes we're asking for, 2) it complicates deployment / the
> operator's life.
In any realistic deployment, the publisher of the TLSA records is
the *same* entity that provisions the certificate chain, anything
else is operationally untenable.
In absence of indirection via SRV records, the only way to combine
DANE with hosting by a provider that is not also managing the
domain's DNS records is to use CNAMEs as follows:
Customer1 DNSSEC zone:
www.example.com. IN CNAME dane-host.example.net.
_443._tcp.www.example.com. IN CNAME _443._tcp.dane-host.example.net.
Provider DNSSEC zone:
dane-host.example.net. IN A 192.0.2.1
_443._tcp.dane-host.example.net. IN TLSA 3 1 1
b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
_443._tcp.dane-host.example.net. IN TLSA 3 1 1
8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f
The client will send an SNI of "www.example.com", which the server
needs to be pre-configured to accept. The server will then return
the corresponding cached CNAME and shared TLSA RRset with all
approrpriate signatures, DNSKEY and DS records.
; per-customer CNAME RR, cached on server.
;
_443._tcp.www.example.org. IN CNAME _443._tcp.dane-host.example.net.
; shared target TLSA RRset, cached on servr.
;
_443._tcp.dane-host.example.net. IN TLSA 3 1 1
b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
_443._tcp.dane-host.example.net. IN TLSA 3 1 1
8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f
With the DANE TLSA records published by the provider, and extension
support deployment across the various server farms also in the hands
of the provider, there is little point in fetching the extension
support lifetime from DNS. Either way the *provider* includes it
with the chain data, but it is much easier to manage it as just
configuration.
The extension support lifetime is a TLS-specific property, and has
no relevance for clients that can (afford to) do direct DNS lookups.
It belongs in the TLS extension and not in DNS.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
