[TLS] dnssec_chain pinning issues and discussion

[Christopher Wood <[e-mail]>]

Thanks to those who contributed to the discussion on this topic over
the past two weeks. It led to useful insights and clarity around the
problem statement, desired use cases, and current state of this draft.
(Specifically, Viktor’s summary of the problem statement in [1] was
quite helpful and, absent objections, would probably make a nice PR
for which we can gauge consensus.) To summarize some of the long
discussions, among the primary use cases raised over the lifetime of
this draft, we have the following:

- Increase availability of DANE records for clients.
- Provide an alternative to WebPKI-based server authentication.
- Gain operational experience with DANE on clients and servers.
- Increase connectivity to DANE-only clients and servers. (This is not
a realistic use case in the immediate future.)

These are meant to apply to both greenfield and incremental deployment
use cases. If there are others, please share them with the list. If
anyone feels as though we should not target the incremental deployment
use case and instead focus strictly on greenfield applications, or if
the current use cases as written are under specified or unclear,
please say so, and say why.

Minimally, for broad use cases, it seems necessary to have some way to
prevent attackers from stripping the additional protection
communicated by this extension from the TLS server to the TLS client.
Extension pinning of some type would seem to address this particular
issue. The text from Paul and Viktor [2] shared before the interim is
one specific proposal for this pinning. In the context of this
proposal, the following issues have arisen:

1. Servers may make mistakes which lead to connection issues, i.e.,
it’s a footgun. (Note: The chance of this happening while the
extension is not yet universally supported is low.)
2. Malicious pins can be set by an adversary who can modify the
victim's DNSSEC records. This can force the TLS client to use the
extension for a long time, even after correcting the DNSSEC
compromise.
3. Some sort of in-band (or perhaps out-of-band) alert may be required
for pinning to function safely and correctly.
4. Non-universal deployment of the extension within a TLS farm
(operator) may make removing the pin difficult since any particular
server may not have an implementation of the extension.

If you feel any of these are non-issues, please say so, and say why.
If you feel any of these issues are incorrect, please say so, and say
why. The chairs would like to have all issues with the *current*
pinning proposal aired and discussed before Bangkok. That will allow
us to asses the proposal and whether or not it satisfies the desired
use cases.

Note that this list may not be exhaustive. Thus, if there are other
omitted issues that have been raised, please share them with the list
for discussion.

Thanks,
Chris, Joe, and Sean

[1] https://mailarchive.ietf.org/arch/msg/tls/OWxALokRtxNcaFdPyNiHTOt_wjQ
[2] https://github.com/tlswg/dnssec-chain-extension/compare/0664d5a608bc2cd82967370160fd4b837dba8fab...vdukhovni:for-interim