I realize I'm not following the TLS working group. I was asked to review this issue by someone who was confused and hurt by the current process and was asking for a less involved opinion. Since I took the trouble to review the document, to review a good chunk of the current list discussion, I decided to share my opinions. I understand that I'm coming at this late. There are both advantages and disadvantages to this.
I will answer the questions, but I ask you to please focus more on my analysis of the proposed change than my answers to the question. I don't think I have anything special to bring to the answers to the questions other than the opinion of someone who is trying as hard as they can to inform themselves. I do think an outsider's evaluation of some of the assumptions and implications of the change may help others make up their mind. 1) Do you support publication in its current form? No. I thought I was going to have to quibble about the question and say that while I supported bringing the document back to the WG I wouldn't go so far as to say I didn't support publication. However, reading the discussion, there are key statements related to the scope of this document that based on current discussion don't seem to have consensus now even though they mmay have had consensus in the past: * The scope discussion in the introduction, particularly pointing out that this document is applicable to web browsers and SIP seems very much under debate in the current discussion. * Section 8 states that using this extension in a TOFU manner would be a reasonable thing to do. I think that absent a mechanism to limit the scope of pinning or to securly move away from this extension that claim is harmful to interoperability and ultimately security. So, even if all we do is remove that text in the introduction and remove the TOFU claim, I think a change is worth the cost. 2) Do you support denial-of-existence proofs and TTL for pinning? Yes, I think this work would be valuable; here's why. First I'd like to explain my understanding of the assumptions under which this change is valuable. You don't need this change if you have reliable client configuration. Reliable client configuration can come in an application where this extension is mandated. That is, you know all your code supports this extension and you know you're being deployed with TLSA records signed up to a trust anchor that the client supports. So say you're only deployed on the public DNS in signed zones. Alternatively reliable client configuration could come in a list of sites that are known to support this extension that is centrally managed. Without that reliable configuration, you won't be able to rely on this extension to improve security for first contact. That's true with or without the proposed changes. With the proposed changes you could implement TOFU semantics in a manner that I and the proponents believe is operationally viable. I think that will provide enhanced security under the following assumptions: * Clients talk to server more than once * There is sufficient value in protecting second and follow-on sessions that mittigation is valuable even though we'll never protect the first session * We trust the DNS root more than our X.509 PKI, or at least we gain enhanced security by validating against both * Clients are willing to pin security information--namely that a given server uses this extension * We're talking about an application where we cannot mandate use of this extension. Remember that you need to mandate not only code support that people actually deploy only with signed dnssec zones and TLSA records before you can mandate the extension. I think those assumptions are common enough that it is worth fixing the problem. That said, I'd like to disagree with Victor on one point. I think for any change there is nontrivial work to be done to get it right and there is a potential downside. His cost analysis seems to imply that there's no chance we'll make things worse with the change and that the only cost is delay. In my discussions, I quickly came across a number of issues surrounding how the proposed changes would interact with private DNS that were more complex than the person asking me to review implied. Victor may have considered all those issues, but I think there is a cost to the change. I think it is worth paying, but I'd urge people to be a bit more realistic about the potential cost of making a mistake or making it more likely people will reduce interoperability by complicating the spec. In conclusion, in ranked order, I prefer: 1) Working on Victor's changes 2) Removing the scope text and TOFU language 3) the current spec 4) no spec ever on this topic _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
