Re: [auth48] AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Section 2:  We had trouble following this paragraph;
"but could be located outside of it" followed by "the latter option
becomes plausible" is a bit confusing.  If the suggested text doesn't
adequately clarify things, would you like to provide alternative text
that does?

Original:
 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 existing VPN client implementations
 might not expect that the discovered DNS resolver IP addresses to be
 outside of the covered IP address ranges of the VPN tunnel.

Suggested:
 For many years, typical designs have often assumed that the DNS
 resolver was usually located inside the protected domain, but they
 don't consider implementations where the DNS resolver could be
 located outside of it.  With encrypted DNS, managing the latter
 scenario becomes plausible.  Note that existing VPN client
 implementations might not expect the discovered DNS resolver IP
 addresses to be outside of the covered IP address ranges of the VPN
 tunnel. -->


2) <!-- [rfced] Section 3.1:  Please clarify the meaning of "to
configure ... to an initiator".

Original:
 The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types,
 ENCDNS_IP4 and ENCDNS_IP6, are used to configure encrypted DNS
 resolvers to an initiator. -->


3) <!-- [rfced] Please review each artwork element.  Should any of them
be tagged as sourcecode?  If the current list of preferred values for
"type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) 
does not contain an applicable type, please let us know.  Also,
it is acceptable to leave the "type" attribute not set. -->


4) <!-- [rfced] Figure 1:  We corrected the field-name mismatch per
"IP Address(es) (variable) - Includes one or more IP addresses" as
listed in the descriptions below.  Please let us know any objections.

Original:
 ~                         IP Addresses                          ~

Currently:
 ~                        IP Address(es)                         ~ -->


5) <!-- [rfced] Section 3.1:  The use of "attribute" versus "attributes"
was confusing here.  We updated the figure title and the next
sentence as follows.  If this is incorrect, please provide a clear
figure title and following text.

Original:
                      Figure 1: Attributes Format

 The description of the fields of the attribute shown in Figure 1 is
 as follows:

Currently:
     Figure 1: Format of ENCDNS_IP4 and ENCDNS_IP6 Attribute Types

 The descriptions of the fields shown in Figure 1 are as follows: -->


6) <!-- [rfced] Sections 3.1 and 3.2:  Should these three instances of
"Configuration Attribute Type" be "Configuration Payload Attribute
Type"?

Original:
 *  Attribute Type (15 bits) - Identifier for Configuration Attribute
    Type.  This is set to TBA1 for ENCDNS_IP4 or TBA2 for ENCDNS_IP6,
    as registered in Section 8.
...
 *  Attribute Type (15 bits) - Identifier for Configuration Attribute
    Type; is set to TBA3 value listed in Section 8.
...
 *  Attribute Type (15 bits) - Identifier for Configuration Attribute
    Type; is set to TBA3 value listed in Section 8. -->


7) <!-- [rfced] Section 3.1:  It looks odd to have 'Length of the ADN'
but no quotes around Length of SvcParams.  May we update as
suggested?

Original:
 -  (4 + 'Length of the ADN' + N * 4 + Length of SvcParams) for
...
 -  (4 + 'Length of the ADN' + N * 16 + Length of SvcParams) for

Suggested:
 *  (4 + 'Length of the ADN' + N * 4 + 'Length of SvcParams') for
...
 *  (4 + 'Length of the ADN' + N * 16 + 'Length of SvcParams') for -->


8) <!-- [rfced] Figure 2:  We found it confusing that the description
for the "Certificate Digest" field only appears after Figure 4.
Will readers readily find the field description, or should some
clarifying text be added?

Original:
 Some of the fields shown in Figure 2 can be omitted as further
 detailed below.

Possibly:
 Some of the fields shown in Figure 2 can be omitted, as further
 detailed below.  Descriptions for the "Authentication Domain Name"
 and "Certificate Digest" fields are provided below Figure 4. -->


9) <!-- [rfced] Section 4:  Per Section 6.2 of RFC 8310 ("Section 8
discusses these mechanisms ..."), should "the mechanism" be "the
mechanisms" here, or should one mechanism in particular from
Section 8 of RFC 8310 be cited here?

Original:
 The DNS client establishes an encrypted DNS session (e.g., DoT, DoH,
 DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the
 mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS
 resolver certificate using the authentication domain name conveyed in
 ENCDNS_IP*. -->


10) <!-- [rfced] Section 4:  Please confirm that "PKIX-EE(1) with
selector SPKI(1)" is correct.  We could only find "DANE-EE(3) and
selector SPKI(1)" and "DANE-EE(3) with selector SPKI(1)" in RFC 7671.

Original:
 This approach is
 similar to certificate usage PKIX-EE(1) with selector SPKI(1) defined
 in [RFC7671] but without PKIX validation. -->


11) <!-- [rfced] Section 4:  The first sentence in the "Note:" paragraph
did not parse.  We updated it as noted below.  Please let us know
any objections.

Also, please review whether the "Note:" paragraph should be in the
<aside> element.  It is defined as "a container for content that is
semantically less important or tangential to the content that
surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Original:
 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 in the
 presence of ENCDNS_IP* attributes.  That is, if ENCDNS_IP*
 attributes are supplied, it is allowed for responders to include
 INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or
 INTERNAL_IP4_DNS) attributes.

Currently:
 Note: [RFC8598] requires that the INTERNAL_IP6_DNS (or
 INTERNAL_IP4_DNS) attribute be present when INTERNAL_DNS_DOMAIN is
 included.  This specification relaxes that constraint in the
 presence of ENCDNS_IP* attributes.  That is, if ENCDNS_IP*
 attributes are supplied, responders are allowed to include
 INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or
 INTERNAL_IP4_DNS) attributes. -->


12) <!-- [rfced] Section 5:  We do not see SHA2-256 mentioned in
RFC 6234.  Will this citation be clear to readers?

Original:
 Implementations MUST support SHA2-256 [RFC6234]. -->


13) <!-- [rfced] Section 6:  Please clarify the meaning of "does not
alter the trust on" in this sentence.  Are some words missing?

Original:
 This document adheres to the security considerations defined in
 [RFC7296].  In particular, this document does not alter the trust on
 the DNS configuration provided by a responder. -->


14) <!-- [rfced] Section 6:  We had trouble parsing this sentence.
Please clarify "returned ENCDNS_IP* resolvers configuration" and
to what "it" refers (the responder or the initiator?).

Original:
 If the IKEv2 responder has used NULL Authentication method [RFC7619]
 to authenticate itself, the initiator MUST NOT use returned
 ENCDNS_IP* resolvers configuration unless it is pre-configured, e.g.,
 in the operating system or the application. -->


15) <!-- [rfced] Regarding the references to IANA subregistries, we note 
that [IANA-IKE-HASH] is normative, whereas [IANA-IKE-CFG] is informative. 
Would you like these both to be one or the other?

For background:
"Normative references specify documents that must be read to understand 
or implement the technology in the new RFC, or whose technology must be 
present for the technology in the new RFC to work. An informative 
reference is not normative; rather, it only provides additional information."
from https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/)

   [IANA-IKE-HASH]
              IANA, "IKEv2 Hash Algorithms",
              <https://www.iana.org/assignments/ikev2-parameters/>.

   [IANA-IKE-CFG]
              IANA, "IKEv2 Configuration Payload Attribute Types",
              <https://www.iana.org/assignments/ikev2-parameters/>.
-->


16) <!-- [rfced] Appendix A.1:  Please clarify the meaning of "There is
no ambiguity to" in this sentence.

Original:
 There is no ambiguity to identify the
 encrypted resolver associated with the supplied digest.

Possibly:
 Identifying the encrypted resolver associated with the supplied
 digest is therefore unambiguous. -->


17) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->


18) <!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 configuration payload attribute (in text; 1 instance) /
   Configuration Payload Attribute (in text; 3 instances)

 Num addresses / Num Addresses (field name)

b) The following terms/expressions appear to be used
inconsistently in this document.  Please let us know which form is
preferred.

 hash algorithm identifiers / 'Hash Algorithm Identifiers' /
   Hash Algorithm Identifiers
   For example:
     included hash algorithm identifiers
     included 'Hash Algorithm Identifiers'
     the Hash Algorithm Identifier
     the hash algorithm identifiers

 set to zero / set to 0 / set to '0'

 the ENCDNS_IP* Configuration Payload Attribute /
   the ENCDNS_IP* Configuration Payload Attribute(s) /
   the ENCDNS_IP* Configuration Payload Attributes

c) Please note that, per elsewhere in this document and per the rest
of this cluster of documents
(https://www.rfc-editor.org/cluster_info.php?cid=C461), we changed
the single-quoted field names to double-quoted.  Please let us know
any concerns. -->


Thank you.

RFC Editor/lb/ar


On Sep 8, 2023, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/09/08

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9464.xml
  https://www.rfc-editor.org/authors/rfc9464.html
  https://www.rfc-editor.org/authors/rfc9464.pdf
  https://www.rfc-editor.org/authors/rfc9464.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9464-diff.html
  https://www.rfc-editor.org/authors/rfc9464-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9464-xmldiff1.html

This diff file compares an altered original and the RFC 
(in order to make the changes in moved text viewable):
  https://www.rfc-editor.org/authors/rfc9464-alt-diff.html

Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9464

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9464 (draft-ietf-ipsecme-add-ike-14)

Title            : Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
Author(s)        : M. Boucadair, T. Reddy.K, D. Wing, V. Smyslov
WG Chair(s)      : Yoav Nir, Tero Kivinen
Area Director(s) : Roman Danyliw, Paul Wouters