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

[David Noveck <[e-mail]>]

I approve all of these changes and feel the document is ready for
publication.

Thanks to the authors and Russ for their work on this.

On Tue, Aug 30, 2022, 3:59 AM Zaheduzzaman Sarker <
[e-mail]> wrote:

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