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

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 08:44:35 -0700

On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters <[email-masked]> wrote:

> On Mon, 18 Jun 2018, Eric Rescorla wrote:
>
> Right but the problem is that accepting the TA for a given domain allows
>> the IPsec endpoint to act as a TLS endpoint for that domain
>> (assuming that the TLS client supports DANE).
>>
>
> Yes. You are the Enterprise customer. It's a feature.

Not all enterprises who use VPNs want to run a MITM proxy.

The basic problem here is that the security properties of DNS are
radically different from those of the WebPKI (which is why we
routinely rely on HTTPS in cases where DNS is untrustworthy).
So, it's totally unexpected that allowing the VPN operator to
inject a new DNS trust anchor would allow them to attack HTTPS
connections. The problem with this design is that it ties those
properties together. This is a problem for the users but also for
the enterprise because it takes something which might have
been offline signed and makes it online.

Client
> implementations can limit these domains, eg using VPN profiles
> that the user has to agree to. There is not much more we can do
> at the protocol leven, than say the two things we already say:
>

> 1) If not split-view, do not accept any DNS trust anchors
>
> This prevents third party VPN providers from injecting rogue trust
> anchors. Note that in this case you already _are_ giving all your
> traffic including DNS to the VPN server. (but hey, we have DOH)
>
> 2) Don't accept trust anchors for anything not specifically
>    split-redirected into the VPN infrastructure
>
> So in my redhat case, I would either allow "redhat.com" or
> "internal.redhat.com" to be redirected through my VPN profile
> and not anything else. (well, actually some reverse zone parts too)
>

There are actually a number of oither things you could do:

- Totally forbid the use of TLSA signed by non-default trust anchors
- Make the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.

I imagine there are other choices.

> Yes, but it's not clear to me that clients can adequately determine which
>> domains
>> are internal -- they just get that information with some VPN config they
>> got
>> from their VPN provider. The text in the document says as much:
>>
>
> Yes. And that is the same DNS problem in general when connecting to a
> network and running your own recursive server. You usually get only one
> domain via DHCP, but universities tend to have dozens, and they demand
> you give them all your DNS queries so they can screw with internal only
> domains for you on the fly. You just have to drop DNSSEC to let them do
> that. That is a situation that needs fixing, and at least if you connec
> to those networks using a VPN, this document is that fix. It allows the
> network to send more than one DNS domain, and let's the client decide
> whether or not to accept it. Where yes, most clients will do this based
> on trusting their administrator of the VPN they are connecting to. Others
> could have VPN software that lets them (de)select the ones they would
> not accept.
>

Trust isn't a monolithic thing. It's one thing to trust the administrator
to route
your packets and quite another to trust them to MITM TLS. Again, this is
why it's mostly safe to use HTTPS on networks owned by other people.

Note that without this document, the only way for VPN clients to get
> functional DNS beyond the 1 hardcoded domain, is to give the VPN all
> your DNS queries, which allows even more manipulation (especially with
> an installed Enterprise CA cert, now they can override gmail.com)
>

I'm not saying this document is bad. I'm saying it should exclude TLSA.

> So it seems to me that the likely consequence of this function is that a
>> lot of
>> clients will be accepting what amounts to MITM certificates (again,
>> assuming
>> that they support DANE) as part of their VPN config.
>>
>
> Not doing this makes the situation even worse. Do you have a proposal
> that would make it better? I cannot think of one.
>

Why does it make the situation worse? Again, what's the use case why
it's needed to have the VPN install a new WebPKI trust anchor.

>
> Also, part of your concerns could be mitigated by CT as well for the
> TLS cases. I assume if browsers require CT, that internal-only domains
> also need to get some kind of CT logging (redacted or not) and that
> would also prevent a rogue gmail.com TLSA from being accidentally
> accepted by the user at the IKE/VPN first as 'internal domain' and
> then additionally at the TLS/TLSA layer?
>

Well, the semantics of CT+DANE are totally undefined, but generally,
no, I wouldn't expect things that were TLSA-authorized to be CTed.
If anything, I would expect them to use some sort of CT-for-DNS, but
of course that doesn't exist. And of course, with raw public keys
that's not even possible.

Paul
> ps. I'd really prefer this discussion to be in public on the list.
> Please do any replies to this to the ipsecme list. You have my
> permission to quote anything I wrote in this offlist mail thread.
>

Sure. We really need aliases that do the right thing here.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 08:54:23 -0700

For reference, here is my original review.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3046

The security considerations seem to omit a fairly serious potential
attack. Consider the case in which the client supplies this payload
and the server provides resolvers and DNSSEC anchors for some domain
it does not actually control, such as www.example.com. It then
provides a bogus IP address (of its own) and a TLSA(2)  or TLSA(3)
record asserting its own key pair. In this case, if the client
supports DANE, then you have at least potentially circumvented the
PKI. This is far more serious than a bogus IP.  The most likely
defense against this is for the client to filter the domains for which
it accepts anchor overrides. However, even if you do that, this still
introduces a weakness: if you are using straight DNSSEC, then signing
can be offline, but because the TA is not signed by an offline key,
compromise of the VPN endpoint means that you can forge DNSSEC
records.

COMMENTS
>
>   2.  Background
>
>      Split DNS is a common configuration for enterprise VPN deployments,
>      in which only one or a few private DNS domains are accessible and
>      resolvable via an IPsec based VPN connection.

I see the "only" binding to one, but isn't also generally the case
that they are only accessible via the VPN connection.

>      o  Digest Type (0 or 1 octet) - DS algorithm value from the IANA
>         Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
>         Registry.
>
>      o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
>         [RFC4034] Section 5.1 in presentation format.

I'm having a little trouble reading this. Is the reason these would be
0 because you are using the empty format?

>      o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
>         [RFC4034] Section 5.1 in presentation format.
>
>   5.  Split DNS Usage Guidelines
>
>      If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,

The rules in this section are kind of hard to follow. I'm not sure
what the best way to restructure them are, but perhaps:  (1) If the
domain list is empty, you can use the internal servers for anything
(2) If the list is non-empty, you MUST use the internal servers for
any entries not prohibited by local policy, including total limits ,
and should accept 1918 addresses fore those domains and SHOULD NOT use
the internal servers for anything else.    -

>      servers.
>
>      If the initiator host is configured to block DNS answers containing
>      IP addresses from special IP address ranges such as those of
>      [RFC1918], the initiator SHOULD allow the DNS domains listed in the
>      INTERNAL_DNS_DOMAIN attributes to contain those Special IP addresses.

I would rewrite this with the SHOULD first,, i..e, "SHOULD allow, even
if" because you want this SHOULD to apply even if you aren't
configured this way.

>      no guarantee of being answered.  For example, if the
>      INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
>      "example.com", "www.example.com" and "mail.eng.example.com" MUST be
>      resolved using the internal DNS resolver(s), but "anotherexample.com"
>      and "ample.com" SHOULD NOT be resolved using the internal resolver
>      and SHOULD use the system's external DNS resolver(s).

This paragraph seems to to some extent duplicate the paragraph
starting with "For each INTERNAL_DNS_DOMAIN..."

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 12:40:55 -0400 (EDT)

> Not all enterprises who use VPNs want to run a MITM proxy.

So only specify INTERNAL_DNS_DOMAIN with "internal.example.com"
and all TA's outside that domain would not be accepted by the client.

> been offline signed and makes it online.

Local policy gives clients the chance to only allow preconfigured
domain(s) to be accepted for redirection over the VPN, with or
without trust anchors. If the network operator is smart, they have
only one internal-only zone in use. And the client accepting that
trust anchor is not a problem. In the case of the network insisting
you need to accept dozens of trust anchors, then yes the network
administrator makes it hard or impossible for their users to engage
in anything other then blind trust of their enterprise devices.
(but to be fair, you are in that situation already when you take
  that enterprise pre-installed laptop)

> - Totally forbid the use of TLSA signed by non-default trust anchors

The IKE/IPsec protocol should not modify the DNS protocol. The fact
that control of a certain (sub)domain is transfered via a private
view reachable via IPsec is a feature, not a bug. That would also break
the use of TLSA records in those private/internal views.

Practically speaking, in my setup, the unbound daemon cannot tell the
difference between trust anchors loaded via IKE/IPsec or via another
method.

> protocol option with those trust anchors defined separately.

That goes against the goal of the protocol. The goal _is_ to place a
certain (internal only) domain fully under control of the network of
the VPN server. Including all security features and trust anchors within
that zone.

> I imagine there are other choices.

This protocol extension is explicitely to add or a move a subdomain in
the public DNS view to a private DNS view, after the user has given
permission for this. Any suggestions to do otherwise is undesired.

> Trust isn't a monolithic thing.

Right, we are in fact carving out a little bit to move that trust
from the public DNS view to a private trusted actor.

> It's one thing to trust the administrator to route
> your packets and quite another to trust them to MITM TLS.

MITM TLS for those domains you have given them permission for.

> Again, this is

And it is _still_ save to use other people's domains unrelated to the
internal vpn zone(s) for HTTPS and no new trust anchors are added
that would compromise that security.

Also, look at it from the reverse perspective. The enterprise might like
the security of their highly valuable non-public servers/data to be higher
then trusting 500+ webpki entities and google/mozilla, patched up with CT.
They might want to rely on DANE/DNSSEC that's actually fully under only
their own organisations sole control, bys using that overriding local
trust anchor. Including for TLSA/HTTPS on their private servers. Why would
you want to prevent them from leveling that extra security?

> I'm not saying this document is bad. I'm saying it should exclude TLSA.

I'm saying that cannot happen without breaking to use of TLSA in
internal networks. Also, then the issue moves to IPSECKEY records
which have an even stronger case to be used with internal DNSSEC
based trust anchors.

How is a DNS server to know which TLSA records to ignore? And are
browsers going to clear their DNS cache when a VPN goes up or down?

Modifying the DNS protocol seems rather unrealistic.

>             So it seems to me that the likely consequence of this function is that a lot of
>             clients will be accepting what amounts to MITM certificates (again, assuming

You could ask IKE client implementations what they plan to do for
INTERNAL_DNSSEC_TA. Our implementation will allow specifying a list
of domains for which you will allow redirection and trust anchors.
And I would set this to "redhat.com, 10.in-addr.arpa" to prevent
the corporate network from installing anything else on my machine.

>       that would make it better? I cannot think of one.

Because in the current situation, the protocol does not allow to request
only DNS queries for one or some domains. You can only ask for none or
all DNS queries. That has a huge privacy impact. So only power users
like us can tweak things like adding a forward_zone to unbound to ensure
only the internal-domain DNS queries go the the server.

> it's needed to have the VPN install a new WebPKI trust anchor.

Because the public DNSSEC view proves the internal view does not exist,
so you need an override.

Because the private DNS wants to use DNSSEC too.

> Well, the semantics of CT+DANE are totally undefined

I was not talking about CT+DANE. I was talking about browsers mandating
CT and browsers not being aware that internal.redhat.com would need to
be treated differently. So even for those internal domains will need to
publish valid CT data (redacted or not) which would further reduce the
effects a malicious INTERNAL_DNSSEC_TA could do even if the client
accepted one for a domain not under enterprise control.

Paul

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 12:04:33 -0500

> and all TA's outside that domain would not be accepted by the client.

What the I-D has to say is that the VPN client MUST support local policy
for what domains it will accept TAs for from the SG.  This is far
simpler for the client than having to have local DNS configuration
including TAs for split-DNS.

A perfectly valid configuration would have the SG MITM all external DNS
too, thus sending the client only TAs for . [and possibly internal
domains if the client only wants those, but then the client will not be
able to use DNSSEC for external domains].  If the client doesn't want
this, then it mustn't use that SG.  In practice, for enterprises, the
client gets no choice, and may even be built, configured, maintained,
and provided by the enterprise.  This I-D would be useful if the
enterprise provides and maintains the VPN client: it makes it easier to
maintain clients by reducing the amount of configuration to update as
keys are rotated or policy changed.

This is just a matter of Security Considerations wordsmithing.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 10:13:47 -0700

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

What, if any, of the above do you disagree with?

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 13:34:59 -0500

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

> records, any TLS client which accepts those TLSA records is subject to MITM

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.

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 15:02:29 -0400 (EDT)

> list . as a domain for which to accept trust anchors.

It already says so:

    If a client is configured by local policy to only accept a limited
    number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any
    other INTERNAL_DNS_DOMAIN values.

However, "limited number" is confusing and it should be reworded to say
"to only accept certain specific domain names"

> property were actually the point of this protocol.

That is all stated in section 6:

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-08#section-6

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 15:07:02 -0400 (EDT)

> list . as a domain for which to accept trust anchors.

Just one note. This draft is mean ONLY for use with split-tunnel VPNs.
If you are sending all traffic over the VPN, then INTERNAL_DNS_DOMAIN
and INTERNAL_DNSSEC_TA are irrelevant and MUST be ignored, because you
are no longer talking about a public vs private view. You are just
changing the entry point to the public view. Was that not clear from
the existing text?

Adding an option for "." as override trust anchor seems unneccessary
for any non-malicious use case I can think of. Can you give an example
of a valid use case?

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 12:26:10 -0700

> 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 SSHFP.  And anything else that might be security-relevent (all of

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

]

> 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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 15:48:38 -0400 (EDT)

On Tue, 19 Jun 2018, Eric Rescorla wrote:

> 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

I don't agree clients have to accept anything. Currently, my iphone will
prompt me with this when installing a VPN Profile:

 	The network traffic of your iPhone may be secured, filtered, or
 	monitored by a VPN server.

It's easy for it to extend this with:

 	The VPN profile is requesting to take control of the domain name(s)
 	"redhat.com"

Or if the VPN profile wouldn't constrain the DNS names, upon connecting
to the VPN it could warn the user and store the decision:

 	The VPN server is requesting to take control of the domain name(s)
 	"redhat.com", "centos.org", "openstack.com".

If it later wants to add "gmail.com", the phone could do the popup
again, and hopefully the user would say no to that.

In addition, the current CT requirements would block rogue attempts by
the VPN server to take over domains not under its control, as a rogue
enterprise certificate for "gmail.com "would not appear in any CT logs,
and the browser would not be aware whether or not this domain would be
a private or public view.

> 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

Again, this is the feature, not the bug. We want to use TLSA records in
the enterprise network.

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

If the server constrained itself in the VPN profile given to the client,
it cannot modify this later on when there is a VPN server compromise.

If the profile did not constrain itself, a popup could ask the user once
the server requests to install trust anchors for new domains.

CT would further prevent a compromised server from making up
certificates for domains not under its control.

If you wanted, you could add some new EKU or HSTS or other TLS
mechanism marking a domain name as never appearing as an
internal zone.

> What, if any, of the above do you disagree with?

The premise that enterprise deployments are a bug instead of a feature.

The premise that this auto-configuration issue is more important than
allowing DNSSEC to be used on internal-only domains and that it cannot
be contained with local client policy.

Compare this to the current webpki, where I don't even get notified by
the browser when it adds/removes a webpki CA that can say anything about
everything on the internet _at all_. It is fully blind trust and I don't
have an enterprise trust relationship with them. Or compare it with
openvpn, that allows the server to execute arbitraty commands on the
client.

There is no IETF protocol that allows for reconfiguration of trust
anchors. If there was, we could have used that here.

A VPN enterprise profile is a trust relationship. This draft tries
to limit the amount of trust the client needs to have while ensuring
that the DNS protocol still works as expected. That is why it does not
support "." or "send everything over the VPN" deployments. I am happy to
clarify text if that is not clear enough, but I think it is unreasonable
to start talking about DNS filters or modifying DNS protocol behaviour
other then the (re)configuration of specific mutually agreed DNS zones
and trust anchors.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 16:00:36 -0400 (EDT)

> to configure their client to accept any domain name.

Which is the equivalent of an enterprise that requires you to accept the
TLS middleware box and its additional webpki CAs. Except we made it more
restrained to prevent abuse.

> WebPKI certs.

It doesn't allow creation of _arbitrary_ webpki certs, only webpki certs
under mutually agreed domain names.

> All that is needed is to be able to authenticate the VPN server itself.

This draft has nothing to do with authentication of the VPN server. That
is all done in IKE, possibly with certificates, but nothing related to
DNS whatsoever. This draft is about using a split-DNS setup where the
VPN client can keep using its own validating DNSSEC capable recursive
server, while allowing a cryptographic acception for mutually agreed
enterprise domains while still supporting DNSSEC for those enterprise
domains to protect against inside attackers.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 13:20:15 -0700

> restrained to prevent abuse.

I'd prefer to establish the facts of the matter before we debate what
ought to happen.

My contention here is that as a practical matter, many clients will be
required
to accept any domain name that the VPN server asserts is internal. As far
as I can tell, this is what the document itself says:

   In most deployment scenario's, the IKE client has an expectation that
   it is connecting, using a split-network setup, to a specific
   organisation or enterprise.  A recommended policy would be to only
   accept INTERNAL_DNSSEC_TA directives from that organization's DNS
   names.  However, this might not be possible in all deployment
   scenarios, such as one where the IKE server is handing out a number
   of domains that are not within one parent domain.

What am I misunderstanding?

> domains to protect against inside attackers.

Yes, I appreciate that point. I was responding to Nico's comment that
"Generally the client must already have a trust anchor for the
SG to begin with. " And it's not correct that in order to have a VPN
gateway, you need to give it a full TA.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 17:46:52 -0500

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

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

> WebPKI certs. All that is needed is to be able to authenticate the

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

> > Internet is going a bit too far.

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 15:51:55 -0700

> you with theirs.  Or just accept it as part of the employment deal.

Again, right now I'm just trying to establish the facts of the matter. Do
you agree
this is going to be a common scenario?

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 18:01:50 -0500

On Tue, Jun 19, 2018 at 03:51:55PM -0700, Eric Rescorla wrote:
> On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams <[email-masked]> wrote:
> > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <[email-masked]> wrote:
> Again, right now I'm just trying to establish the facts of the matter.
> Do you agree this is going to be a common scenario?

I don't know what the antecedent of "this" in your question.  If you
mean that BYODs will have to accept policies users don't want, well,
that's pretty much true anyways (e.g., you have to accept proxy
configurations that can and _will_ MITM you).

For public VPNs (that the user pays for) the user will want the client
to accept TAs for no domain.  For private VPNs the user will generally
not really have a choice.

I don't think there's a question of what is a common scenario, but of
what the I-D should say.  It should say that with these TAs the SG can
MITM DNSSEC and DNSSEC-based security technologies like DANE, and it
should say that clients MUST be able to configure a list of domains for
which they'll accept TAs.  And that should be sufficient to handle your
concern.

Are you objecting to the I-D altogether -- objecting to the feature it
adds -- or asking what the I-D should say about your concern?

Objecting to enterprise features would be fair, though I don't think the
IETF rejects enterprise features, nor should it.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 16:11:13 -0700

> configurations that can and _will_ MITM you).

I'm asking if a common scenario will be that users of enterprise
VPNs who implement this feature will end up in a situation where the
VPN can impose TAs for any domain.

As a followup question, I claim that that's not presently true with
existing VPNs. In some cases, the VPN requires you to install
a new trust anchor in order to accept its cert, but that's not an
inherently necessary practice. Separately, an enterprise may
require you to accept an MITM cert, but these are conceptually
distinct. Do you disagree with that?

> adds -- or asking what the I-D should say about your concern?

Again, right now I'm trying to establish the facts of the matter. I'd prefer
to do that prior to discussing what is good or bad.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jun 2018 19:31:24 -0400

> On Jun 19, 2018, at 18:46, Nico Williams <[email-masked]> wrote:
> 
> 

Opportunistic IPsec exists and are “promiscuously”. And the draft opens the Security Considerations section with:

The use of Split DNS configurations assigned by an IKEv2 responder is predicated on the trust established during IKE SA authentication. However, if IKEv2 is being negotiated with an anonymous or unknown
endpoint (such as for Opportunistic Security [RFC7435]), the initiator MUST ignore Split DNS configurations assigned by the responder.

Paul

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 18:41:53 -0500

> VPN can impose TAs for any domain.

I think that will be (and probably already is) common in enterprises,
but not for public VPNs.

> distinct. Do you disagree with that?

Requiring that the client accept arbitrary trust anchors in this
protocol is "not an inherently necessary practice" practice either.

Do you disagree?

The protocol's purpose is to enable split-dns, not to enable MITM for
all domains, though it does also do the latter if the client accepts it.

> Again, right now I'm trying to establish the facts of the matter. I'd
> prefer to do that prior to discussing what is good or bad.

My prediction of which configurations will be common is hardly a fact :)

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Jun 2018 18:42:47 -0500

On Tue, Jun 19, 2018 at 07:31:24PM -0400, Paul Wouters wrote:
> Opportunistic IPsec exists and are “promiscuously”. And the draft
> opens the Security Considerations section with:

But is it opportunistic VPN?  Regardless, that's fair enough.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 00:38:20 -0400 (EDT)

> VPN can impose TAs for any domain.

I explained before that I think "for any domain" can be strictly limited
on the client side, either by preconfiguration or by confirmation on the
VPN client side.

In IKEv1, the XAUTH attribute relaying the domain name typically only
appears once. When checking the Cisco documentation, I see:

 	domain name

 	Example:

 	Router (config-isakmp-group)# domain cisco.com

 	Specifies the Domain Name Service (DNS) domain to which a group belongs.

This does not suggest that there can be more than one. So my educated
guess here is that implementations in IKEv1 typically did not support
setting more the one domain name (we only support sending and receiving
one). Note that the _use_ of the domain name attribute in IKEv1 is a bit
unclear. Is it to be used only for resolv.conf style search lists, or was it
to constrain the domain(s) that should be looked up with the supplied
nameserver IPs?

Again speaking for our implementation, if we detect a local DNS server
running, we use the domain name and the obtained nameserver IPs to
reconfigure the DNS server to add a forward for only this domain name
via these nameserver IPs. If we did not find a local DNS server running
we will add the domain to the search option in /etc/resolv.conf and
prepend the nameserver IPs to /etc/resolv.conf. (and on termination of
VPN, we restore the old resolv.conf)

So I think most Enterprise configurations will only use one domain,
but most likely still expect the client to give them all DNS traffic
so they can just take over or make up any domains they want. With
more validating (stub) resolvers on devices, this will become more
problematic over time, and I suspect these networks will have to
consolidate things under their own internal domain. Because even if
the VPN will allow multiple domains via this draft, wifi and LAN
connections don't support this.

> inherently necessary practice.

Note that the VPN server authentication is not under discussion here
at all. I'm not sure why you keep bringing this up.

You almost certainly will need to install some local webpki trust anchor
to make use of your internal TLS servers reachable via the IPsec VPN.

For example, to reach any of our internal redhat servers over HTTPS, I
need to install a redhat internal CA into my system/browser. I believe
this is extremely common (although I do hope it is less common to give
these internal CA's the CN="Certificate Authority")

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 22:22:39 -0700

> on the client side, either by preconfiguration or by confirmation on the

Yes, that's technically true, but the question is whether it's in fact
practical for people to do that. I'm sorry to repeat myself, but once
again the document clearly states that this can happen:

Is that text wrong? If not, I suspect we're just quibbling about "common".

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 10:15:41 -0400 (EDT)

On Tue, 19 Jun 2018, Eric Rescorla wrote:

> practical for people to do that.

I already responded before that yes I think it is practical.

> I'm sorry to repeat myself, but once

I also answered this question twice already. If you are waiting for a
trigger in any possibly answer, why not just tell us what that trigger
is and we can discuss it?

> Is that text wrong? If not, I suspect we're just quibbling about "common".

I can clarify the text if you tell me what is bothering you. Or you can
suggest text.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jun 2018 11:03:31 -0700

> I already responded before that yes I think it is practical.

Perhaps I have misunderstood you, but that's not what I have been getting
out of this conversation.

> I can clarify the text if you tell me what is bothering you.

I thought I had made clear what was bothering me, so I suppose we must be
talking past each other. I read this text as saying that there are
important cases where in fact the client will not have any reasonable  way
of knowing which domains to accept from the server, which, it seems to me,
contradicts the claim above that it's practical. You obviously think i'm
wrong, so how should I be reading this text?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 15:21:52 -0400 (EDT)

On Wed, 20 Jun 2018, Eric Rescorla wrote:

> I thought I had made clear what was bothering me, so I suppose we must be talking past each other. I read this text as saying that there are
> important cases where in fact the client will not have any reasonable  way of knowing which domains to accept from the server, which, it seems
> to me, contradicts the claim above that it's practical. You obviously think i'm wrong, so how should I be reading this text?

I understand what bothers you. You see browsers getting non-public TLSA
answers and you are concerned about webpki bypass and enterprise
meddling.

I see text restricting and notifying users of the domain names that will
be part of the IKE configuration or negotiation allowing them to reject
inappropriate domains.

You fear the user will just click yes. Then you somehow would like to
know how common this new behaviour would be and how reasonable it is
for a client to understand what is happening. I cannot answer how common
this would be other than stating in the past this wasn't possible at
all. And that client understanding could be presented cleanly and I gave
an example.

To me, the only question is how to change the text so this is all clear
to you, but you say you are still gathering facts and you are not ready
yet to evaluate any proposed changes.

Maybe some other people can chime into this discussion and/or provide
text to clarify things to you better than I am able to.

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 14:32:28 -0500

> You fear the user will just click yes. Then you somehow would like to

This seems like the main fear, yes, but perhaps not exclusively so.
It's kind of how users "always" click through certificate warnings in
browsers, or "alway" grant a mobile app all the requested permissions.
If, to expand unreasonably upon a previous example, connecting to the Red
Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com,
rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com,
realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it
reasonable to expect the user to look at the list and pick out
"realham.googleapps.com" as not belonging?  Maybe they think it's a
codename for some Red Hat project, but maybe it's something totally
unrelated and reflects overreach by the VPN provider.

It seems to border on unreasonable to have such a long list and expect user
knowledge.  On the one hand, the VPN provider "ought to know" what domains
it's responsible for (and are on the internal view), but on the other hand
this is essentially a self-certification and does not inherently have any
level of trust.  It would be great if there was some third party that could
provide some certification that the list of controlled domains is valid, or
at least not present in the public view and controlled by someone else
(since there will presumably be cases when internal names are not expected
to be visible in the public view at all).  I'm not coming up with a great
technical solution off the top of my head, though.  "Something in the public
DNS" might work, if you can forgive the incredibly vague idea.

> all. And that client understanding could be presented cleanly and I gave

I think it will be very common for users to "click through" without
actually looking at the list, with fairly high confidence.  I expect (but
at a lower level of confidence) that it will also be common for enterprises
to have lists of more than three domains in the internal view.

-Benjamin

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 15:55:02 -0400 (EDT)

> unrelated and reflects overreach by the VPN provider.

If you are thinking of such a large list, then this information could be
conveyed via the Enterprise VPN Profile that the user must install. Then
you could either not allow any changes from that profile without updating,
or you could decide as a client to present only new names to the user.
This is all local policy between enterprise server and client. Just like
the mandatory use of some algorithms can be (and are) set in those profiles.

> at least not present in the public view

Names might be present in the public view and private view. That is not
a valid criteria.

> and controlled by someone else

If you solve the Public Suffix list problem, there are more people
interested in how they can use that information :) Although again,
draft-pwouters-powerbind comes close to offering that functionality.

> DNS" might work, if you can forgive the incredibly vague idea.

That would mean publishing something about private domains in the public
dns and worse publishing something in the parent zone about child zones,
which would be next to impossible for second level domains.

> to have lists of more than three domains in the internal view.

If you do not make this option available at all, then the only option
for the enterprise VPN's are:

- Conveying this information hardcoded in installation profiles without
   any user visibility or negotiation/rejection posibility
- Demanding to just get all DNS traffic despite being a split-tunnel
   VPN, at the expense of the user's privacy when doing DNS lookups for
   things that are not supposed to go into the VPN tunnel. Possibly
   requiring the user disables DNSSEC completely.

Note also that the harm that can be done with realham.googleapps.com is
basically the same as with any typosquat domain name, like me getting
rhel.googleapps.co or realham-googleapps.com. I think that is not the
real issue here. The issue is missing facebook.com, twitter.com or
gmail.com in a long list of domains. And those would have a much higher
chance of being seen as inappropriate.

If it helps we could limit the number of INTERNAL_DNS_DOMAIN payloads
or INTERNAL_DNSSEC_TA payloads allowed to put an artificial cap on
these lists. I personally don't think we should, but I wouldn't object
to one either if it is not too low.

The reality is that using an Enterprise VPN means letting the
enterprise control part of your machine. If the enterprise is malicious
or incompetent, than there is nothing you can do as enduser. If
anything, allowing this draft gives the VPN client a better chance to
compartmentalize what it gives the Enterprise VPN. It is simply not
different from the mandatory enterpise CA and/or anti-virus you have
to install. If you think that risk is too high, you should not use the
enterprise hardware for anything not related to the enterprise, and BYOD
for personal matters.

To greatly reduce any abuse, the draft disallows any of these CFG
payloads for those VPNs that are not split and take all traffic. If the
VPN client is using its own validating resolver, the remote VPN cannot
falsify any TLSA records. This covers the use case of all commercial VPN
providers out there, some of which are pretty malicious.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jun 2018 23:20:31 +0300

> these internal CA's the CN="Certificate Authority")

Reading this thread now, I have few comments.

1) The current practice (before this draft) for split-dns is as
   follows: Forward ALL traffic to SGW when VPN is up (includes all
   DNS, including traffic to 8.8.8.8 etc). Forbid sending any traffic
   out except through VPN.

   Mandate that clients will install Enterprise Root CA to the trust
   anchor list of the client (i.e., operating system global trust
   anchor list). The client will have that Enterprise Root CA
   configured always, i.e., regardless whether VPN is up or not. Those
   Enterprise Root CAs do not have name constrains (as they do not
   work) or anything else that will limit their use for creating
   certificates for any domain name in world (CT might help). I.e., to
   be able to access enterprise https protected sites you MUST install
   the Enterprise Root CA, and to do anything useful you need to do
   that.

   One reason they want to do this is to limit what client can send
   out, for example make sure it cannot send any email out directly
   but all emails must go through the enterprise SMTP server which
   will do virus checking, add stupid disclaimers to them. They also
   want to do virus and malvare verification on all web traffic, thus
   they will want to use that Enterprise Root CA for MitM of all web
   traffic, or they might mandate the use of proxy that does the
   checking. If you want to connect your bank etc, do not use your
   enterprise laptop for that...

2) With this protocol, we can have Split-dns setup where the server
   can say that my "internal.local" domain is served by 10.0.0.1 and
   which has TA of XXX. This will provide much better security, as now
   enterprise can get rid of the Enterprise Root CA which allows MitM
   of whole web, and instead they can provide local TA configured
   DNSSEC protected TLSA records for all internal services. I.e.,
   after this there would no longer be need to require installing of
   the Enterprise Root CA just to get internal services working.

   I.e., we want to use TLSA which is protected by local TA to protect
   the internal servers. This is why we do not want to filter TLSA
   records out.

   Enterprise might still want to use Enterprise Root CA to do the
   MitM for virus etc checking, but this is outside the scope of this
   protocol.

3) Usually enterprises try to configure their internal domains to only
   include very limited number of domains, as the more you have those,
   the more issues you will have with configation.

   Quite often they use something that does not exists at all outside
   the enterprise. I.e., names like .internal, .local, .enterprise,
   .company-name.

   Sometimes they use names that do exists in outside world, but which
   are not owned by them (yes, this can and will happen, most commonly
   when they start using some foo.bar domain, and then someone decides
   to register .bar top level domain).

   If they are smart they use some domain owned by them which do have
   external visible name servers, and use some subdomain there which
   might not exist outside, i.e. internal.example.com.

   The reason why they end up with multiple internal domains is
   because every acquisition, merge etc usually adds some new names,
   and it takes years to get rid of them all. I think in my last
   employer we had about 5-8 different internal domain names in total
   during last 20 years, but only 1-2 were in use in the end.

4) If the enterprises have very complicated network they will usually
   have management system (or MDM) that will automatically configure
   the clients for them. I.e., the device is fully configured by the
   management system, and they will automatically apply configuration
   changes when needed. I think most of those system do allow
   completely take the device in their control, i.e., most likely they
   can silently install the Enterprise Root CA there if they want, or
   push device updates which include any code they want...

   In those cases the security of the device is in the hands of the
   enterprise anyways, and users might not even have permissions to
   change anything on the devices.

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.

As I said in complicated cases the configuration itself might come
from the management system, so client does not need to silently accept
what server says, it can always verify it against the list it has in
configuration. But as the list comes from the enterprise this does not
protect the client from the malicious enterprise, but it does protect
it against case where attacker manages to hack in to the SGW, but was
not able to gain access to the management system. It most likely will
not protect against case where the attacker hacks in to the management
system, as the SGW configuration might also come from there...
-- 
[email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Jun 2018 17:06:25 -0500

On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote:
> [...]

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?

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jun 2018 02:56:58 +0300

> 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-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Jun 2018 19:26:43 -0500

Agreed.

Now, is the concern enough to reject this I-D?

Nico
--

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 27 Jun 2018 12:36:45 -0700

It seems like the conversation here stalled out a bit.

From my perspective, the feeling in the working group is that the functionality described in the document for dealing with Split-DNS and DNSSEC is the best thing we can do given enterprise deployment models, as long as it is clear that client must validate TAs against configured local policy.

I think the text that Paul added recently does aim at clarifying this point. Are there specific nits or changes we want to see in the text there? I’d like to see this document be able to progress soon in a way that everyone is satisfied with.

Thanks,
Tommy

> On Jun 20, 2018, at 5:26 PM, Nico Williams <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Jun 2018 20:01:16 -0500

Sorry for the slow response; several things colluded to keep me
unavailable.  For bonus fun, mutt crashed trying to send this so I get to
try to reconstruct from scrollback history.  Hopefully nothing important
gets garbled along the way...

Do note that this is not really my area of expertise and is also not a WG
I'm responsible for, but I'm trying to help brainstorm a way past this
apparent impasse.

> the mandatory use of some algorithms can be (and are) set in those profiles.

Sure ... and local policy between the enterprise server and client could
also have the ability to actually show the list to the user.  (There's not
really a great reason for the enterprise to choose to do so, but if we're
hiding behind "local policy matter", we can keep our options open.)

> Names might be present in the public view and private view. That is not

It's not entirely clear that a true third party would be needed.  Perhaps a
cross-signed (by public and private keys) statement of joint ownership
could be visible in the private DNS, for example.  Yes, that's a logistical
hassle to arrange, but we're still in the "is the crypto possible" stage
for this question and can optimize eventually.

> draft-pwouters-powerbind comes close to offering that functionality.

So, at some philosophical level, the public Internet is "more important"
for IETF standards than private Intranets.  Yes, it would be nice if our
Internet protocols can be used elsewhere, but in lots of places we use as
criteria "benefit the public Internet", "not harmful to the public
Internet", etc..  It may seem that in a case where there is conflict
between the public Internet and the private enterprise Intranet (e.g., when
the same name is controlled by a different entity in the two locations)
that we the IETF are obligated to prefer the public Internet.  I'm not
generally a huge fan of trying to use one IETF protocol as a forcing
function for some other change we want to see, but sometimes it happens,
and "if you want TLSA in the enterprise you can't have it for random
namesquats that mean something else in public" may be a valid case.

Does the public suffic list necessarily come into play?  If I walk up the
hierarchy looking for the same DNS key in both views, then force the first
level of divergence to have some authorization for the private view, would
that work?

> which would be next to impossible for second level domains.

Sure.  "Put it in the public DNS" is approximately the first easy thing
that came to mind.  What about my other proposal above?

>    any user visibility or negotiation/rejection posibility

See my previous note about "local policy", which has no technical reason to
prohibit user visibility.

>    requiring the user disables DNSSEC completely.

Yes, this is bad.

> to one either if it is not too low.

That doesn't seem like a great plan to me, either, though I suppose I could
live with it if it ends up being the consensus proposal.

-Ben