Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

Chuck Lever <> Mon, 31 August 2020 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B90F63A14B2; Mon, 31 Aug 2020 08:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5hTnlFR9EJki; Mon, 31 Aug 2020 08:06:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 093F73A0905; Mon, 31 Aug 2020 08:06:55 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 07VF5Xx1130430; Mon, 31 Aug 2020 15:06:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=cwF/GXqKh9XgC5PBHqj8guVaxFNKOR7OxMNaThSQN2E=; b=MS/I9sV2IVV1lQ+RUr5at+x5SHJlJX1lIzKdtaqaT7/zBCZ/rgOymmh+wKMugcyUfcb5 npiAlM4VMH0WPNUXJHWWGsCxLdnpzzv9q2a3ukrB+5cE6wrKwWYmjIJN7L4NuTM3UhfL xtMNBL6UPdc9oR/yH6MB22XXzlHcquKMUY5zshFjaaQLllETUUlPR9YshcdUlEaToUXB KYzSOJUOKSsT820iEpq0DngEO3DGBewoezYwWr9xUZq76WgK0s7gxxTNrR5qhxE+Z0rv hliGawkO+LFKkFIuE5g6YwNvJTyJFfMGxkABpsvhP8dkqp2UThAWy5MYF9vg9xTrB6oR eg==
Received: from ( []) by with ESMTP id 337qrhdubb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 31 Aug 2020 15:06:54 +0000
Received: from pps.filterd ( []) by ( with SMTP id 07VF5b9l068143; Mon, 31 Aug 2020 15:06:54 GMT
Received: from ( []) by with ESMTP id 3380xuvm4x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 31 Aug 2020 15:06:54 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 07VF6q87004183; Mon, 31 Aug 2020 15:06:53 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 Aug 2020 08:06:52 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Chuck Lever <>
In-Reply-To: <>
Date: Mon, 31 Aug 2020 11:06:51 -0400
Cc: The IESG <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9730 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310090
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9730 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 spamscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310090
Archived-At: <>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2020 15:06:58 -0000


I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
current Editor's Copy with these changes can be found here:

In this e-mail I will try to address some of the simpler-to-manage
DISCUSS comments from your position. I plan to address the more complex
issues in subsequent e-mails.

I will also follow up with questions and proposals for addressing
COMMENT points in subsequent e-mails.

> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: 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.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I support Roman's Discuss points.

I believe I've now addressed his DISCUSS points to his satisfaction,
and welcome your review of the new version of the document at the
link above.

> (1) I don't think that the claim in Section 4.2 that "[b]oth RPC and TLS have
> peer and user authentication" is correct, at least given my understanding of
> those terms.  Using this document's definition of RPC "peer authentication"
> as analogous to TLS server authentication, the functionality that TLS calls
> "mutual authentication" is more analogous to RPC client authentication,
> though it is sometimes repurposed for use for user authentication, with
> concommittant bad user experience.  This analogy does not seem critical to
> the mechanisms of this document, so I believe we should remove or modify it.

Perhaps it's a matter of terminology. RPCSEC_GSS "peer" authentication
is truly mutual. For AUTH_SYS, both peers identify themselves by a name
string in the RPC headers, though this is not cryptographically strong
and thus is typically ignored by receivers.

I'm open to specific suggestions about how to modify the text.

> (2) The mention of using RPCSEC_GSS with GSS channel bindings to TLS is
> quite underspecified. Unfortunately, this is largely the fault of other
> specifications, but we have to deal with the fallout.  On first glance (but
> subject to further clarification/change), it seems like we should:

I'm deferring a response to (2) until I've reviewed the kitten documents
you've mentioned. IMO introducing specific instructions for handling GSS
channel binding is appropriate, and I intend to propose text in a
subsequent e-mail.

> (3) Please check this reference in Section 5.1.1:
>   Reverse-direction operation occurs only on connected transports such
>   as TCP (see Section 2 of [RFC8166]).  [...]
> It seems likely that RFC 8167 was intended...

I agree. I'll fix this.

> (4) I don't think it's particularly safe to suggest that non-protected RPCs
> should be exchanged on the same 5-tuple that just terminated a DTLS
> association, since neither DTLS nor UDP provide in-order delivery, so there
> is ambiguity as to whether a datagram should be interpreted as DTLS
> protected or not.  This is particularly problematic in the face of the three
> different DTLS record headers (DTLSPlaintext, DTLSCiphertext(full), and
> DTLSCiphertext(minimal)) with something like 10 or 11 different possible
> values for the first byte that might be in flight, with limited "magic
> number" verification fields available.  I think I need some input from the
> TSV ADs about what the options are, though -- while a cooling-off period
> might be fine if an ephemeral port is in use, it seems problematic for cases
> where fixed port numbers are used for both source and destination.

This is a more complex issue, but I'm replying here to inquire if
you've yet been able to circle back with the TSV ADs. Additional
input is welcome.

> (5) Section 5.2.1 requires that:
>   *  Implementations SHOULD indicate their trusted Certification
>      Authorities (CAs).
> Indicate to whom?

The text is vague, but I assume based on context that the RPC-over-TLS
implementation indicates the list of trusted CAs to the RPC server to
make final decisions about authorization.

> (6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
> intent.

I'm deferring a response to (6) until I've reviewed RFC 6125 again.

> (7) Section 5.2.1 uses the phrase "renegotiate the TLS session".
> Renegotiation is not defined or allowed for TLS 1.3; generally one would
> need to either remember the presented certificate and re-run the validation
> process on it or shutdown the TLS connection and make a new one, though in
> theory one could try to define a mechanism using post-handshake
> authentication.  (I don't recommend the latter, though; it's not widely
> implemented/used.)


implementations MAY renegotiate the TLS session to reassess the
connecting peer’s continued authorization.


implementations MUST terminate the TLS session.

> (8) Can we clarify the status of DNSSEC (or DANE) requirements? Section 1
> assumes that support for DNSSEC is already available in an RPC
> implementation, but Section 7.1.1 says that "Clients [sic] implementors can
> choose from" a list of things including DANE TLSA records.  Why would we
> require DNSSEC support but not using the records if they're present?

I'm deferring a response to (8) until I've reviewed specifications of
other consumers of DNSSEC/DANE.

> (9) I agree with Roman('s comment) that Sections 5.2.2 and 5.2.4 should give
> a minimum amount of information to be exposed to the administrator for
> implementing the trust mode.

Section 5.2.2 (Certificate Fingerprints) has been removed because of a
variety of unresolvable issues.

Section 5.2.4 (Token Binding) has been removed because there is currently
no active Internet-Draft or plan to support token binding in TLS 1.3.

We are leaving these areas open for future standards work.

Chuck Lever