On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <n...@cryptonector.com> wrote:
> 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. > The ID can say that, but as a practical matter, any enterprise that has a reasonable number of internal domains is just going to tell people to configure their client to accept any domain name. > 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). > Well, different parts of DNS are differently security relevant. For instance, the IP-address mapping usually isn't that big a deal because the network attacker can reroute you anyway. 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. Why? That trust anchor doesn't need to allow the creation of arbitrary WebPKI certs. All that is needed is to be able to authenticate the VPN server itself. Painting this as a security threat to the entire > Internet is going a bit too far. > Why? -Ekr
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
