> On Apr 5, 2018, at 9:33 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> However, that doesn't mean that hijacking isn't a problem (though I agree a
> less
> serious one). If I have no provisions for DNSSEC at all and the attacker does
> pin hijacking I could be offline for hours to days while I figure out how to
> get
> and serve them.
Perhaps you did not see my explanation of why the pin imposes no obligation
beyond
supporting the extension in the server software. A server for an unsigned
domain
can just serve denial of existence of the domain's (or a parent's) DS record.
So you don't need to "get and serve them", you just need to forward whatever is
the true data in DNS about the server's domain. Only the capability to present
the actual DNS chain is required.
* If server's zone is not DNSSEC-signed, forward NSEC records showing
existence of NS and non-existence of DS at or above the requested:
_443._tcp.server-fqdn.example
domain and the requisite signatures up to the root.
* If server's zone is DNSSEC-signed, but no TLSA records are present,
serve
NSEC records proving non-existence (or NODATA) of the requested
_443._tcp.server-fqdn.example IN TLSA ?
records and the requisite signatures up to the root.
* If the server's zone is DNSSEC-signed, and TLSA records are present,
serve
the requested TLSA records along with the requisite signatures up to
the root.
All three of these would be obtained and cached (up to most of the advertised
TTL) in
the same way from a suitable resolver that supports chain queries, it is up to
that
resolver to return the appropriate response each of the above cases, the server
can
treat the data as opaque, modulo determining the time for which it may cache the
response so that the chain need not be re-fetched for each client connection.
If one is worried about hijack by someone who can cause the domain to be signed
with TLSA records published (so as to set a non-zero pin), then one might be
motivated to have server software that is capable of returning the extension.
Just as with STS one might need software that supports TLS if the hijacker
deployed STS. I don't think that such hijacking is a major risk, but if that
risks drives adoption of the extension (without any other changes in tbe
domain's practices wrt. DNSSEC or DANE adoption) all the better. :-)
The domain might need the extension some day for more than just hijack recovery,
and it will already be available.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
