Nico Williams writes: > On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote: > > Reading this thread now, I have few comments. > > > > [...] > > > > So I think the feature that we can use TLSA records in the split-dns > > is very important. I agree that it would be VERY BAD for the client to > > just accept whatever domains server sends, and it SHOULD always verify > > it against its local configuration. > > Agreed. > > But I also think that a REQUIREMENT that the client support and check > local policy as to which domains to accept TAs for is sufficient to > address the concern. Isn't it?
Yes and no. Yes, I think that is best we can do. No, I do not think it will necessarely solve the problem, as there will be implementations where they might have the local policy checks, but there is no way to edit that list (or even see that list), because this list comes and is managed by the management system or profile. I.e., the feature might be there, but it is useless as it is filled up by the enterprise. Of course there is trust relationship between the VPN client and the enterprise. All this information is transmitted inside the IKEv2 SA which is authenticated, thus client is able to trust the information it gets from the SGW. Then client simply needs to decide whether it trusts the enterprise enough to allow it do the things it tries to do. Asking user does not really help, as if there is popups the users will simply click them away. Very often this already happened for some internal servers already for TLS. Some people did not install the Enterprise Root CA, or the certificate used for the service expired and nobody bothered to update it, or the service used actually self-signed certificates, or the service used different internal domain name than the user tried to use etc. More often than not the intranet sites gives all kind of certificate errors when you are connecting to them, thus in enterprise environments people ignore the warnings always... Hopefully with this we might actually be able to use TLSA records for those internal sites, and that might fix some issues (or at least break them in different ways :-) -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
