On Nov 26, 2018, at 7:59 PM, Paul Wouters <p...@nohats.ca> wrote: > This discussion would be better if people took warren’s example and then read > the draft before commenting.
I don't think that the answer changes much as a result of this, but it does change a little. You've obviously put a lot of thought into how to put this particular square peg into a round hole. It might be worth backing off a bit and looking at the use cases that I think you care about. Here are six, roughly in order of how bad an idea they are, worst idea last: Split DNS, no DNSSEC Split DNS, DNSSEC, no trust anchor required because validation works on both sides of the split Split DNS, DNSSEC, trust anchor required because the hidden zone provably doesn't exist Split DNS, DNSSEC, trust anchor required because the hidden zone is under or at an unsigned delegation Split DNS, DNSSEC, trust anchor required because the hidden zone has a secure delegation that won't validate I want to attack you, and you want to let me I am going to claim that case [1] is the use case that you really care about. If you could just address case [1], you'd be nearly done. Case [2] is a use case you care about if you are a DNSSEC fan. Let me know if you need me to explain how to do it, but I assume you already know how. Neither case [1] nor case [2] require the client to get trust anchors from the VPN provider. A third vaguely plausible use case is that the service provider has a hidden domain that isn't correctly delegated, like .corp. I think you can make an argument that this is a valid use case, and it does require that a trust anchor be installed. The mitigation strategy for this would be to check to see that the existence of the zone is securely denied. If so, and this is the case for example for .corp, then we can use the trust anchor without worrying that some legitimate public zone will be shadowed. However, we still have the problem that two different versions of .corp could be configured at once. Maybe not the scariest problem in the world, but okay, let's say this is a valid use case, and you can specify precisely how to allow it. Probably check every time it's used to make sure its existence is still denied. I think this use case makes sense for fake TLDs, and in no other case, so validating it is easy. In cases four and five, you care enough to set up DNSSEC, but either can't be arsed to do it right, or don't have control over the delegation point and so can't do it right. In the former case, I would argue that we should just say too bad. In the latter case, we have just protected the end user from being attacked by saying too bad. So I would argue that in both cases four and five, it should be impossible to install a trust anchor. This is easy to do: when you are online, check to see if there's a secure path to an unsigned delegation above the zone. If there is, then you can't use any trust anchor presented for that zone. If you can't check, then you can't use the trust anchor either. Secondly, check to see if there is a secure delegation. If there is, you can't use the trust anchor. If you can't check, you can't use the trust anchor. I'm glossing over the fact that there are two steps to the process: installing the whitelist, and installing the trust anchor. I think it would be fine to do the checks when installing the whitelist, and then validate them every so often, maybe at least once a day. There may be use cases where this prevents goodness from happening, but I think that we should let the field tell us before figuring out how to solve that problem. One thing that the document says that absolutely must be taken out: there should be no way for a VPN to do something that presents me with a security dialog where I can decide whether not to allow it to whitelist a trust anchor. That's not a valid use case. This is case six. I think that the use case you want to address here is that an enterprise provisioning system needs to install a whitelist. This is not a user action. The user should never be asked to do this, and should not even be able to do this unless they are smart enough to know that they need to do it and know how to do it without any prompting. So the document should be quite explicit about that, and not recommend a UI flow that enables a social engineering attack.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
