I think the bottom line is that how risky this is really depends on the implementation. I can live with what's in the document on the basis that I think the major OS vendors aren't stupid, and I hope this isn't going to get stuffed into random cheap router firmware, but I'd definitely be happier if the use case were more constrained and the implementation advice were clearer.
One thing that I really don't like is the text that talks about users being presented with confirmation messages. That is an extremely bad message to put into this document. The user should never ever ever see an offer to install one of these whitelists. That's just the wrong UI flow. On Wed, Nov 28, 2018 at 4:54 PM Warren Kumari <war...@kumari.net> wrote: > So, thank you everyone for commenting / the feedback... > > I've been mulling this over, and, while I really don't like it, I think > that the: > "IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use > a whitelist of one or more domains that can be updated out of band. > IKE clients with an empty whitelist MUST NOT use any > INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY > interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- > whitelisted domain as an indication that their local configuration > may need to be updated out of band." > > helps mitigate this -- as Tero says above, the user would have to jump > through many stupid hoops in order to make themselves vulnerable. > 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. > > 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. > > Can anyone *not* live with this? > W > > > 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
