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

[[e-mail]]

Hi Paul, 

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters <[e-mail]>
> Envoyé : dimanche 7 mai 2023 21:44
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Paul Wouters <[e-mail]>; The IESG
> <[e-mail]>; [e-mail]; ipsecme-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-
> add-ike-11: (with DISCUSS and COMMENT)
> 
> On Tue, 25 Apr 2023, [e-mail] wrote:
> 
...
> >> #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.
> 

[Med] OK, removed that sentence.  

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

[Med] We removed A1/A2/A3.

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

[Med] That other "1" is about the address count. This is why we are referring to an "address" not "addresses". Made this change "s/Its IPv6 address (2001:db8:99:88:77:66:55:44)/Its single IPv6 address (2001:db8:99:88:77:66:55:44)".

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

[Med] OK.

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

[Med] The following comments do not apply anymore as we removed the appendices.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.