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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
