Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

On Tue, 25 Apr 2023, [e-mail] wrote:

>> #2 Updates RFC 8598
>>
>>         Note: [RFC8598] requires INTERNAL_IP6_DNS (or
>> INTERNAL_IP4_DNS)
>>         attribute to be mandatory present when INTERNAL_DNS_DOMAIN
>> is
>>         included. This specification relaxes that constraint
>>
>> This clearly updates RFC8598, but the document is lacking an
>> Update: clause.
>> Please add the Update clause and mention the update in the
>> abstract/introduction.
>>
>
> [Med] Please refer to this thread: https://mailarchive.ietf.org/arch/msg/ipsec/1Mi1_ygETzgA4t1OGbArbn9eqBk/

Ok, thanks. I will leave this decision to the responsible AD / IESG.

>> #3 Security Considerations
>>
>>         The initiator may trust the encrypted DNS resolvers
>> supplied by
>>         means of IKEv2 from a trusted responder more than the
>> locally
>>         provided DNS resolvers, especially in the case of
>> connecting
>>         to unknown or untrusted networks (e.g., coffee shops or
>> hotel
>>         networks).
>>
>> This does not seem to be a "Security Consideration".
>> Also, before this draft, receiving an (unencrypted) DNS server
>> supplied
>> by IKEv2 would also be more trusted. In general, VPN clients trust
>> the
>> "VPN provided nameserver" more than the local network one,
>> irrespective
>> of transport encryption. Perhaps this sentence can just be
>> deleted?
>>
>
> [Med] The intent of the text is to remind the precedence of IKE supplied data over local supplied resolvers (even if those are encrypted resolvers).

Nothing this draft does changs that from before. I still don't think
it adds anything and in the case of split vpn is not entirely true
either. But it is not my hill to die on.

> I do not understand the point that
>> A.2 is
>> trying to make?
>>
>
> [Med] In addition to the answer from Valery, another point of this appendix is that some app may not fall back to Do53.

I still do not understand. I doubt you can talk about what VPN providers
"expect".


>> Similarly, I don't understand Appendix A.3. The VPN service is not
>> involved
>> in "allowing" an application to send traffic through the tunnel.
>
> [Med] This is not what the text says.


>> It is the
>> VPN client that decided whether or not to send its traffic through
>> the tunnel
>> or not. Also VPNs typically are configured to be either split-
>> tunnel or not.
>
> [Med] The text focuses on the case of split-tunnel VPN configuration.
>
>> This can be, be hardly ever is, dynamic.
>
> [Med] The text does not say that.
>
> I don't understand what
>> A.3 is trying
>> to convey as example use related to the encrypted dns capability
>> of the
>> document.
>>
>
> [Med] This is to provide some background to motivate the discussion about INTERNAL_DNS_DOMAIN in Section 4.

If the section is about setting or not setting INTERNAL_DNS_DOMAIN to
certain values, then it should do so.

I still don't think A2 or A3 provides anything useful to the document.

>> Which explains one of the number "1"s in the Figure which is
>> otherwise
>> unreferenced.

The idea here is that the other "1" should also be described here.

>> The placement of "AliasMode" confuses me. It appears as part of
>> the
>> Service Priority as a field name, but it is not a mode or value of
>> that. Perhaps the text should be moved somewhat down, after the
>> listing od fields? (It is also somewhat confusing in the reference
>> document I-D.ietf-dnsop-svcb-https.
>>
>
> [Med] svcb says "SvcPriority is a number in the range 0-65535". We have that text there to explain why 0 is not allowed. I suggest to leave the text there. Thanks.

Then make it part of the previous paragraph so it is clear what value
is talked about, eg:

CURRENT:

 	Service Priority (2 octets) - The priority of this attribute
 	compared to other ENCDNS_IP* instances. This 16-bit unsigned
 	integer is interpreted following the rules specified in Section
 	2.4.1 of [I-D.ietf-dnsop-svcb-https].

 	AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not
 	supported because such a mode will trigger additional Do53 queries
 	while the data can be supplied directly in the IKE response. As
 	such, this field MUST NOT be set to 0.

NEW:

 	Service Priority (2 octets) - The priority of this attribute
 	compared to other ENCDNS_IP* instances. This 16-bit unsigned
 	integer is interpreted following the rules specified in Section
 	2.4.1 of [I-D.ietf-dnsop-svcb-https]. As AliasMode (Section 2.4.2
 	of [I-D.ietf-dnsop-svcb-https]) is not supported, this field
 	MUST NOT be set to 0.



>> Note that, VPN clients might have code that specifically prohibits
>> the
>> use of DNS servers on IP addresses that are not covered by the VPN
>> tunnel.

Thanks for adding a warning note about this.

>> I also have some concern with the word plausible, as that seems to
>> only take
>> encryption into account and not redirection or privacy concerns
>> towards
>> the encrypted DNS server, or what could be monitored from an
>> adversary
>> seeing the encrypted DNS stream not protected by the VPN to a DNS
>> server.
>
> [Med] These privacy concerns fall under this part of the security considerations "the use of encrypted DNS does not reduce the data available in the DNS resolver".

That's not entirely true as there is a connection between what to
trust more, the local network or the VPN. You always seem to assume
the VPN is more trustworthy (from an encryption and privacy point of
view) which does not take into account other views. Again, this is
not my hill to die on, but I find the text punting to a non-VPN
encrypted DNS case not really matching what is required in this
document's security and privacy considerations.

>> This example does not make it clear if the encrypted DNS resolver
>> can be
>> used for all DNS or not.
>
> [Med] I guess you are referring to the example in A.1. Isn't this explicit in this text right before the one you quoted: " For both split- and non-split-tunnel configurations, the use of encrypted DNS instead of Do53 provides privacy and integrity protection ..."?

No it does not. In a split-tunnel, it could be that only DNS lookups for
the internal domains are allowed. Or it could be that ALL DNS lookups
are allowed, even for non-enterprise use cases. But this is not signaled
in any way AFAIK. The extreme case is a VPN service whose only supported
traffic is DNS (eg think ExpressVPN SmartDNS). It is a "split tunnel"
but it is meant to get all DNS traffic.


> It appears to say there is a limitation
>> to only
>> use it for internal-only domain names. I do not think such a
>> protocol
>> limitation should be implied by this example?

So the problem is your clarifying text in split/no-split implies a
protocol feature that is not actually part of the defined protocol.
("split tunnel means only send DNS for INTERNAL_DNS_DOMAINS")

Is "." a valid INTERNAL_DNS_DOMAINS ?

Paul