On 29. 11. 18 1:47, Paul Wouters wrote: > On Nov 29, 2018, at 04:53, Warren Kumari <war...@kumari.net > <mailto:war...@kumari.net>> wrote: >> helps mitigate this -- as Tero says above, the user would have to jump >> through many stupid hoops in order to make themselves vulnerable. > > That’s what we came up with when we talked to ekr. > >> If think that if the text around "that can be updated out of band" >> were strengthened (the current wording sounds like being updated out >> of band is one option, but e.g being updated in-band and "approved" by >> the user is another), and it were made a bit clearer how the whitelist >> might be managed I'd be (grudgingly) willing to remove my DISCUSS. > > I have no problem making that text stronger / clearer. > >> Again, I don't love this, but I think that the mitigations can be made >> to work, and it *does* solve a real world problem. > > Yes, if we want enterprises to deploy DNSSEC, we need this. The > internal/external views are almost always administrated by a different > party, so the likelihood of sharing private key is extremely unlikely > (plus we would be telling them how to run their infrastructure). > >> Can anyone *not* live with this? >> W > > I’m fine with the phrasing changes you are requesting. > > Paul
I'm wondering if we could add NXDOMAIN mandatory check and accept INTERNAL_DNSSEC_TA only if "external DNS server" resolves given name to NXDOMAIN. It seems to me that it would eliminate most problematic cases like com. hijack etc. Only problem I can see are cases where "external view" actually serves non-NXDOMAIN answers - I have no idea how common is that. What do you think? Petr Špaček @ CZ.NIC >> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen <kivi...@iki.fi >> <mailto:kivi...@iki.fi>> wrote: >> >> Tony Finch writes: >> > Joe Abley <jab...@hopcount.ca <mailto:jab...@hopcount.ca>> wrote: >> > > >> > > It seems to me that the intended use-case is access to >> corporate-like >> > > network environments where intranet.corporate-like.com >> <http://intranet.corporate-like.com> might exist on >> > > the inside but not on the outside. >> > >> > More likely cases like corporate-like.local or >> corporate-like.int <http://corporate-like.int> or >> > like.corp etc. usw. :-( >> >> Yes, this is the more common practice to use. I.e., several companies >> quite often have (multiple) internal domains they use. Because those >> are internal domains they cannot get real certificates for them. >> Because they cannot use real certificates they use self signed >> certificates, thus users have to click on "trust this web site having >> invalid certificate yes/no". The idea is that with TLSA we could get >> some kind of security for those internal sites. >> >> More competent companies might also run their own CA and use that to >> sign internal web sites, but unfortunately those more competent >> companies usually then also have heavy IT processes that requires all >> kind of complicated stuff to get things be signed by corporate CA, and >> then developers setting up intranet / chat system / testing setup etc >> revert to self signed certificates, because it is easy. On the other >> hand getting DNS names added to the internal DNS is usually something >> that happens often, and is not too hard to do, getting TLSA record >> along with the name should also be quite easy. >> >> Now when browsers start to make it harder and harder to allow access >> to self signed certificates, users are seeing more and more problems >> with that. >> >> > Private DNSSEC trust anchors should be distributed in the same way >> > that you would distribute corporate X.509 trust anchors. >> >> This is exactly what is proposed by the draft, execpt that it is split >> in two parts, i.e., the names for which TAs can be given are >> distributed in same way as X.509 trust anchors, the actual contents >> for the TA for that whitelisted name is distributed inside IKE. >> >> The draft requires the whitelist to pre-configured before starting up >> the VPN connection. It also do require implementations to ignore all >> those settings unless user have explictly configured split-tunnel on >> for that connection. >> >> I.e., in the example the VPNs-R-Us would not be able to set those >> configuration settings, nor would it be able to provide dialog asking >> that. >> >> VPN-R-Us would require provide instructions how to configure your VPN >> client to do that, i.e., it would need to ask users to do following: >> >> - In your IPsec VPN configuration dialog click "Add" to add new >> VPN. >> - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address. >> - Click advanced >> - In Advanced settings to go the enterprise VPN tab >> - In there click the Enable Split-tunnel setup check box. >> - Answer YES to question verifying that you really want to configure >> this manually, and do not want to use the managment profile >> provided by the enterprise (normally enterprise VPN setups are >> managed automatically by profiles provided by the company, normal >> users usually do not even have option to change anything). >> - After that click "Add items to DNSSEC whitelist". >> - Type in "farfetch.com <http://farfetch.com>", and click OK. >> - (vpn client would probably forbid him adding .com to list as or if >> it is added it would be ignored), so VPN-R-Us is smart and asks >> following: >> - Type in "paypal.com <http://paypal.com>" and click OK. >> - Click OK to few times and get the VPN configuration setup. >> - Then fire up the VPN client. >> >> More likely VPN-R-Us would say if you do not want to do that, just >> download this easy binary exe that will do all that configuration for >> you (and some others they do not mention). >> >> I.e., that whitelist needs to be modified out of band. Usually it is >> done by the management system taking care of the enterprise profiles, >> i.e., the same program that installs X.509 roots for the company CA, >> and mandates that virus checkers are up to date before allowing >> connection to the corporate network, and which also configures the VPN >> connection too. >> >> If you are running that kind of programs you have already given all >> control to whoever provided you that program (VPN-R-Us, or the >> enterprise). >> >> In enterprise case, you usually do not have option not to, as those >> softwares come pre-installed and you cannot uninstall or not to use >> them. On the other hand do not use your work laptop to go to paypal, >> if you do not trust your company... >> >> And yes, the enterprise (or VPN-R-Us) management.exe could also >> install those TAs directly for the global system use without any >> problems. This would not be problem for the VPN-R-Us (they would be >> happy to have fake TA in your system even when you are not using their >> VPN), but enterprise might not want to have its TA there when you are >> not connected to its network, just to limit the exposure, and they >> might want to update the TA contens, even when the whitelisted domain >> name stays same. >> >> I.e., if the TAs cannot be transmitted and agreed to be taken in use >> (after comparing them to whitelist) inside the IKE, then enterprises >> will most likely just install them by the management system for >> general use (or not use DNSSEC). I think that would weaken security >> more than what is proposed in this draft. >> -- >> kivi...@iki.fi <mailto:kivi...@iki.fi> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants.. >> ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
