Re: [IPsec] draft-pauly-ipsecme-split-dns

[Nico Williams <[e-mail]>]

On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote:
> On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <[e-mail]>
> wrote:
> > 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.

And what's the problem with that?

If it's your own device you might balk, so get your employer to provide
you with theirs.  Or just accept it as part of the employment deal.

The I-D should have Security Considerations text about it and that's
that.

> > 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.

Yes, a Security Considerations note should be a) required, b)
sufficient.

> > > 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.

Why on Earth would I connect to some random SG I don't know?

> > Painting this as a security threat to the entire
> > Internet is going a bit too far.
> 
> Why?

Because my VPN clients don't connect promiscuously.  I can't say no
promiscuous VPN clients exist, but I imagine that none do.  And any
promiscuous VPN clients get what they deserve.

Nico
--