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

[[e-mail]]

Hi Paul, all, 

Thanks for the review. 

Please see inline. Skipped the comments to which Valery replied. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters via Datatracker <[e-mail]>
> Envoyé : mardi 25 avril 2023 01:21
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11:
> (with DISCUSS and COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-add-ike-11: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
...
> 
> 
> 
> ------------------------------------------------------------------
> ----
> DISCUSS:
> ------------------------------------------------------------------
> ----
> 
> I have a few important items I believe needs fixing, but I believe
> those are
> still fairly easy to address.
> 
...
> #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/

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

> #4 Appendix A.2 and A.3
> 
>         Legacy VPN service providers usually preserve end-users'
> data
>         confidentiality by sending all communication traffic
> through an
>         encrypted tunnel.
> 
> What is "legacy" about this? 

[Med] We mean traditional VPN providers. The word is now removed.

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.  

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

> 
> ------------------------------------------------------------------
> ----
> COMMENT:
> ------------------------------------------------------------------
> ----
> 
> Appendix A and B are marked as "example". This is confusing. I
> would rename
> Appendix B to "Configuration Payload examples".
> 
> The Figure 5 text should add the line:
> 
>         * Its Service Priority is 1
> 

[Med] ACK.

> Which explains one of the number "1"s in the Figure which is
> otherwise
> unreferenced.
> 
> 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.

> 
>         Note that, for many years, typical designs have often
> considered
>         that the DNS resolver was usually located inside the
> protected
>         domain, but could be located outside of it. With encrypted
> DNS,
>         the latter option becomes plausible.
> 
> 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.
> 
> 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". 

> (eg an adversay sees an encrypted DNS packet to 192.1.2.1, and
> then sees
> a plaintext query to the root server for ohnoos.org from IP
> 192.1.2.1).
> Note that based on this reasoning, perhaps a consideration for
> this should
> be added to the Privacy Considerations section.
> 
> I would remove this note or rewrite it as a caution note instead,
> eg:
> 
>         Note that existing VPN client implementations might not
> expect
>         the new use case of an obtained DNS server IP being
> outside of
>         the covered IP ranges of the VPN tunnel.
> 

[Med] Makes sense. Went with this reworded text: 

NEW:
Note that existing VPN client implementations might not expect that the discovered DNS resolver IP address to be outside of the covered IP address ranges of the VPN tunnel.  

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


 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?
> 
>         Enterprise networks are susceptible to internal and
> external
>         attacks. To minimize that risk all enterprise traffic is
> encrypted
>         (Section 2.1 of [I-D.arkko-farrell-arch-model-t]).
> 
> I'm not sure if this sentence is relevant to the document in
> question? Or
> actually, if all enterprise network is encrypted anyway, why cant
> one just
> send "unencrypted DNS", encrypted over the VPN to the VPN server?
> The VPN
> server would then encrypt that traffic to the target internal DNS
> server
> using its regular "all enterprise traffic is encrypted" model. I
> suggest
> to just remove this sentence.

[Med] OK. 

> 
> 
>         Hosting encrypted DNS resolvers even in case of split-VPN
>         configuration minimizes the attack vector (e.g., a
> compromised
>         network device cannot monitor/modify DNS traffic).
> 
> I think "minimizes" should be changed to "can minimize". For
> example, if the
> encrypted DNS is hosted on the VPN server itself, the above claim
> is not true.
> 

[Med] Changed. 

> 
>         In this example, the initiator uses the ENCDNS_DIGEST_INFO
>         attribute to indicate that the encrypted DNS client
> supports
>         SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash
> algorithms.
> 
> Can we add "for certificate digests" to this sentence. I was a bit
> confused
> when I read this and saw support for hash algorithms and wondered
> what
> the list of hash algorithms was for again.
> 

[Med] ACK.

> 
>         In this example, no ADN is included ...
> 
> Because this sentence is between two examples, it is really
> confusing as to which
> example it belongs to. how about:
> 
>         In the following example, no ADN is included ...
> 
> 

[Med] The sentence refers to the previous, not the following example. Added a pointer to avoid confusion. Thanks. 


_________________________________________________________________________________________________________________________

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.