Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Petr Špaček <[e-mail]>]

On 29. 11. 18 1:47, Paul Wouters wrote:
> On Nov 29, 2018, at 04:53, Warren Kumari <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Tony Finch writes:
>>     > Joe Abley <[e-mail] <mailto:[e-mail]>> 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.
>>     -- 
>>     [e-mail] <mailto:[e-mail]>
>>
>>
>>
>> -- 
>> 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