Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla <[e-mail]>]

On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Apr 5, 2018, at 9:33 AM, Eric Rescorla <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>