On Tue, 25 Apr 2023, mohamed.boucad...@orange.com 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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
