On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > 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. > Yes, so quite possibly I need to upgrade my entire server farm, which might be running on some software which has no version which implements this extension. This could be an enormous effort. -Ekr - > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
