On Nov 29, 2018, at 04:53, Warren Kumari <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 > >> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen <kivi...@iki.fi> wrote: >> Tony Finch writes: >> > Joe Abley <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 might exist on >> > > the inside but not on the outside. >> > >> > More likely cases like corporate-like.local or 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", 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" 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 > > > -- > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
