[nfsv4] Concensus call for draft-ietf-nfsv4-rpc-tls (RFC to be 9289) on AUTH48 changes

[Zaheduzzaman Sarker <[e-mail]>]

Hello working group,

draft-ietf-nfsv4-rpc-tls-11 is in AUTH48 state and there are substantial changed since -08 version in response to different reviews. All these are good.

I have also seen the previous plan for updates (https://mailarchive.ietf.org/arch/msg/nfsv4/Enoo1fkQPxaf4CupTZddTarDQNQ/). However, due the sheer amount of changes in the normative language, I would like to catch the attention of the working group again to the changes. Here is diff from -08 version https://www.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-rpc-tls-08&url2=draft-ietf-nfsv4-rpc-tls-11&difftype=--html.

Please review the changes and confirm/disagree with those within next one week ( ends on 06th September, 2022). When I see confirmation and absent any crucial drawbacks, I will approve the changes.

Following changes are not considered as editorial by the RFC editor and needs AD approval.



1.

<!-- [rfced] Section 5: *AD, in the following paragraph, normative text was removed between versions

-10 and -11. Please let us know if you approve of the update:



Version -10:



   *  Negotiation of a ciphersuite providing confidentiality as well as

      integrity protection is REQUIRED.  Support for and negotiation of

      compression is OPTIONAL.



Version -11 and Current:



   *  Negotiation of a cipher suite providing confidentiality as well as

      integrity protection is REQUIRED.

->



2.

<!-- [rfced] Section 5.2.1: *AD, from version -10 to version -11, text was added to the beginning of

the first two bullets of the following list. This new text may impact the interpretation of the

normative text that follows it. A third bullet containing normative text was also added. Please

review and let us know if you approve of these additions:



Version -10:



   *  Support for the DNS-ID identifier type [RFC6125] is REQUIRED in

      RPC-over-TLS client and server implementations.  Certification

      authorities that issue such certificates MUST support the DNS-ID

      identifier type.



   *  DNS domain names in RPC-over-TLS certificates MUST NOT contain the

      wildcard character '*' within the identifier.



Version -11 and current:



   *  The DNS-ID identifier type is a subjectAltName extension that

      contains a dNSName, as defined in Section 4.2.1.6 of [RFC5280].

      Support for the DNS-ID identifier type [RFC6125] is REQUIRED in

      RPC-over-TLS client and server implementations.  Certification

      authorities that issue such certificates MUST support the DNS-ID

      identifier type.



   *  To specify the identity of an RPC peer as a domain name, the

      certificate MUST contain a subjectAltName extension that contains

      a dNSName.  DNS domain names in RPC-over-TLS certificates MUST NOT

      contain the wildcard character '*' within the identifier.



   *  To specify the identity of an RPC peer as a network identifier

      (netid) or a universal network address (uaddr), the certificate

      MUST contain a subjectAltName extension that contains an

      iPAddress.

->



3.

<!-- [rfced] Section 5.2.1. *AD, between versions -10 and -11, text was modified in the following

normative statement ("trust base" was changed to "set of trust anchors"). Please review and let us

know if you approve.



Verion -10:



   When the configured trust base changes (e.g., removal of a CA from

   the list of trusted CAs; issuance of a new CRL for a given CA),

   implementations SHOULD reevaluate the certificate originally

   presented in the context of the new configuration and terminate the

   TLS session if the certificate is no longer trustworthy.



Version -11 and current (we have expanded the acronyms CA and CRL in the following):



   When the configured set of trust anchors changes (e.g., removal of a

   Certificate Authority (CA) from the list of trusted CAs; issuance of

   a new Certificate Revocation List (CRL) for a given CA),

   implementations SHOULD reevaluate the certificate originally

   presented in the context of the new configuration and terminate the

   TLS session if the certificate is no longer trustworthy.

->



4.

<!-- [rfced] Section 5.2.2. *AD, please review the following normative text that was modified

between versions -10 and -11 and let us know if you approve.



Version -10:



   At least the following

   parameter of the TLS connection SHOULD be exposed at the RPC layer:



   *  PSK Identifier



Version -11 and current:



   The PSK Identifier SHOULD be exposed at the RPC layer.

->







The only non-version-related approval we require from you is the addition of Section 7.4, which can be seen here:



https://www.rfc-editor.org/authors/rfc9289-auth48diff.html


//Zahed