On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey <j...@salowey.net> wrote: > 1. Do you support the working group taking on future work on a pinning > mechanism (based on the modifications or another approach)?
I don't think that pinning is a good idea. We've experience that suggests that it's more of a footgun than a useful mechanism. That isn't to say that there isn't a domain where it makes sense. > 2. Do you support the reserved bytes in the revision for a future pinning > mechanism? No. We need fewer extension points, not more. It's already hard enough to ensure that the ones we have remain usable. ekr's suggestion to reduce the number of *types* of extension point would be a compromise position here, but I don't think that's the best outcome. If we mess this one up, we can make another extension, or use another extension to fix it if that makes more sense. Yes, that's messy, but the above assessment supports the notion that we won't need v2. > 3. Do you support the proof of denial of existence text in the revision? Allowing denial of existence in the extension is fine. It somewhat depends on having a prior expectation of having some form of DNSSEC record there, which hits all the concerns above, so I'm not sure what concrete value it provides. I see no harm in allowing it though. > 4. Do you support the new and improved security considerations? I have to confess, I had a lot of trouble reading the new text. It's good, and contains much of what is needed, but it's very wordy. I think another iteration or two would help. If I can summarize: We consider the case where DANE is considered stronger than PKIX or a valuable addition to PKIX, because this extension is only of use in those circumstances. If an attacker can compromise PKIX, then they can just not send the DANE extension. With prior knowledge, a relying party might know to expect DANE, but that isn't always possible, especially when this mechanism is introduced into a PKIX-only ecosystem. A relying party can't assume that use of DANE with one connection implies that other connections to the same peer will also be secured with DANE. There's a lot of extra words around that message, and I fear that the message will be lost as a result. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
