Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

[[e-mail]]

Hi Paul, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec <[e-mail]> De la part de Paul Wouters
> Envoyé : lundi 8 novembre 2021 16:20
> À : Tero Kivinen <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> On Mon, 8 Nov 2021, Tero Kivinen wrote:
> 
> > Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> >
> > This is the start of 2 week WG adoption call for this document, ending
> > 2021-11-22. Please send your reply about whether you support adopting
> > this document as WG document or not.
> 
> I support the idea of conveying a list of DNS servers that support
> encryption. I am not sure if this draft's format and content is the right
> way forward.

[Med] Thanks. The format can always be updated to reflect the feedback from the WG.

> 
> Note the text of the draft claims it updates RFC 8598 but doesn't do so
> via an Updates: statement.

[Med] We considered to have an "update" header because we were concerned with some MUSTs in 8598. We finally didn't include the update header because of a comment we received from you prior to publishing the first version of the draft. FWIW, here is the exchange we had at that time: 

******
Med: I have a question for you: now that we don't depend anymore on INTERNAL_IP*_DNS and given that a client can be supplied with 8598 attributes and that 8598 says the following:
 
==
If an INTERNAL_DNS_DOMAIN attribute is
   included in the CFG_REPLY, the responder MUST also include one or
   both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the
   CFG_REPLY. 
 
..
 
   the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a
   single list of Split DNS domains that applies to the entire list of
   INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.
 
==

Should we add an update to our daft to indicate that first "MUST" does not apply and that the domains are associated with **ANY** supplied server?

Paul: You cannot update that RFC for that kind of processing. The above really says that it makes no sense to have "internal domains" without providing "internal DNS servers".
****


 Also, I think the relaxing of the requirement
> is actually wrong, as it might cause lack of interop between newer servers
> and older clients not being able to negotiate working DNS if the new
> servers no longer serve INTERNAL_IP*_DNS CFG payloads.

[Med] Older clients can always ask for INTERNAL_IP6_DNS or INTERNAL_IP4_DNS. We will update the note to make this clearer. 

> 
> I am also not clear on the real use of negotiating hash algorithms for the
> digest receiving of the ADD server "identity?", as the document states the
> authentication happens as per Section 8 of [RFC8310] which lists WebPKI or
> DANE authentication against the name and these methods do not use this
> digest. I also do not understand the use of the digest. For
> authentication, is it not needed as the entire IKEv2 exchange is
> authenticated.

[Med] We added the digest to address one of the comments raised in a previous ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS server certificate but convey the end-entity certificate in IKEv2 itself.

> 
> Paul
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec

_________________________________________________________________________________________________________________________

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.