On Tue, Jun 19, 2018 at 10:13:47AM -0700, Eric Rescorla wrote: > I don't think that going point-by-point is getting us very far, so I'm > going to try to restate what i think the situation is, from the top. > > 1. In the current design, many clients (those whose enterprises have any > significant number of domains) are just going to have to accept whatever > domains the VPN server claims should be treated as internal, and to accept > the trust anchors the VPN server claims
The I-D should say that clients MUST allow local configuration of what domains to accept trust anchors for, and SHOULD allow local policy to list . as a domain for which to accept trust anchors. This local configuration should be per-SG. > 2. Because the current design also allows those trust anchors to sign TLSA > records, any TLS client which accepts those TLSA records is subject to MITM > by the VPN server And SSHFP. And anything else that might be security-relevent (all of DNS, really). This definitely merits a Security Considerations note even if this property were actually the point of this protocol. > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that > any compromise of the VPN server automatically makes it an MITM proxy for > the Internet as a whole, because the person who compromises it can simply > reconfigure it to advertise any domain of its choice as internal, as well > as the corresponding keys and TLSA records. Sure, but it's not like clients will be choosing to connect to any VPN servers. Generally the client must already have a trust anchor for the SG to begin with. Painting this as a security threat to the entire Internet is going a bit too far. > What, if any, of the above do you disagree with? (3). Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
