Using RPC-with-TLS with DNS-Based Authentication of Named Entities
draft-cel-nfsv4-rpc-tls-dane-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Chuck Lever | ||
| Last updated | 2026-10-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cel-nfsv4-rpc-tls-dane-01
Network File System Version 4 C. Lever, Ed.
Internet-Draft 2 October 2026
Updates: 9289 (if approved)
Intended status: Standards Track
Expires: 5 April 2027
Using RPC-with-TLS with DNS-Based Authentication of Named Entities
draft-cel-nfsv4-rpc-tls-dane-01
Abstract
RPC-with-TLS assumes that DNS-Based Authentication of Named Entities
(DANE) is available on platforms where it is deployed, and recommends
that a client operating under an opportunistic security policy check
for a TLSA record before initiating an association, but does not say
how. This document specifies the missing details, so that a TLSA
record authenticates an RPC server with no certification authority
trust anchor provisioned on the client. It updates RFC 9289.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://chucklever.github.io/i-d-rpc-tls-dane/draft-cel-nfsv4-rpc-
tls-dane.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-dane/.
Discussion of this document takes place on the nfsv4 Working Group
mailing list (mailto:nfsv4@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/nfsv4/. Subscribe at
https://www.ietf.org/mailman/listinfo/nfsv4/.
Source for this draft and an issue tracker can be found at
https://github.com/chucklever/i-d-rpc-tls-dane.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Lever Expires 5 April 2027 [Page 1]
Internet-Draft RPC TLS with DANE October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Updates to RFC 9289 . . . . . . . . . . . . . . . . . . . . . 6
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8
4.1. DANE policy modes . . . . . . . . . . . . . . . . . . . . 9
5. TLSA Records for RPC Services . . . . . . . . . . . . . . . . 10
5.1. Owner names . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Alternate ports . . . . . . . . . . . . . . . . . . . . . 10
5.3. Port provenance . . . . . . . . . . . . . . . . . . . . . 11
5.4. Publishing and key rollover . . . . . . . . . . . . . . . 11
6. The Reference Name . . . . . . . . . . . . . . . . . . . . . 11
6.1. Requirements on the reference name . . . . . . . . . . . 11
6.2. Destinations that carry no DANE binding . . . . . . . . . 12
7. Locating the TLSA RRset . . . . . . . . . . . . . . . . . . . 13
7.1. Resolver trust . . . . . . . . . . . . . . . . . . . . . 13
7.2. DNS outcome classes . . . . . . . . . . . . . . . . . . . 13
7.3. Candidate TLSA base domains . . . . . . . . . . . . . . . 14
7.4. Evaluation and result reduction . . . . . . . . . . . . . 15
7.5. Usable records and digest algorithm agility . . . . . . . 17
7.6. The selected TLSA base domain, SNI, and reference
identifiers . . . . . . . . . . . . . . . . . . . . . . . 18
8. Authenticating the Server . . . . . . . . . . . . . . . . . . 18
8.1. Certificate usages . . . . . . . . . . . . . . . . . . . 18
8.2. DANE-EE(3) . . . . . . . . . . . . . . . . . . . . . . . 19
Lever Expires 5 April 2027 [Page 2]
Internet-Draft RPC TLS with DANE October 2026
8.3. DANE-TA(2) . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Required client behavior by outcome class . . . . . . . . 20
9. Downgrade Resistance . . . . . . . . . . . . . . . . . . . . 21
9.1. The security floor . . . . . . . . . . . . . . . . . . . 21
9.2. AUTH_TLS probe outcomes . . . . . . . . . . . . . . . . . 22
9.3. Cleartext fallback . . . . . . . . . . . . . . . . . . . 22
9.4. Failure after a handshake is attempted . . . . . . . . . 23
9.5. Coherence within an association attempt . . . . . . . . . 24
10. Association Scope and Policy Granularity . . . . . . . . . . 24
10.1. Policy is per association . . . . . . . . . . . . . . . 25
10.2. Transports joining an association later . . . . . . . . 25
10.3. Derived associations . . . . . . . . . . . . . . . . . . 25
11. Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
12.1. tlshd (ktls-utils) . . . . . . . . . . . . . . . . . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13.1. What DANE authentication does and does not establish . . 28
13.2. Replay and the limits of revocation . . . . . . . . . . 28
13.3. Fail-closed behavior is a denial-of-service surface . . 29
13.4. Unauthenticated port selection . . . . . . . . . . . . . 30
13.5. Derived associations . . . . . . . . . . . . . . . . . . 31
13.6. Privacy considerations . . . . . . . . . . . . . . . . . 31
13.7. Client authentication . . . . . . . . . . . . . . . . . 31
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Deployment Considerations . . . . . . . . . . . . . 34
A.1. Publishing TLSA records for RPC services . . . . . . . . 35
A.2. Unsigned zones prove nothing . . . . . . . . . . . . . . 36
A.3. Downgrade resistance of opportunistic DANE . . . . . . . 36
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
RPC-with-TLS [RFC9289] protects Remote Procedure Call [RFC5531]
traffic by encapsulating it in a TLS [RFC9846] session. A client
discovers whether a server supports the mechanism by sending a NULL
procedure carrying the AUTH_TLS authentication flavor, in cleartext,
before the TLS handshake begins. A server that supports RPC-with-TLS
replies with a "STARTTLS" token, after which the client sends a
ClientHello on the same connection or to the same UDP destination
port.
Lever Expires 5 April 2027 [Page 3]
Internet-Draft RPC TLS with DANE October 2026
Section 5.2.1 of [RFC9289] requires every RPC-with-TLS implementation
to support authenticating server certificates by PKIX [RFC5280] trust
against a locally configured expected DNS-ID. The client resolves
that name in the DNS to reach the server, but the DNS supplies
nothing that authenticates the server or that says the server is
expected to speak TLS. Two deployment problems follow:
* Trust anchor distribution. Every client must be provisioned with
the certification authority material needed to validate the
servers it will contact, and kept current as certificates are
rotated. A server operator without a certification authority has
no way to tell clients what key to expect other than by
configuring each of them.
* STRIPTLS. The AUTH_TLS probe and its reply are exchanged in
cleartext. An on-path attacker who suppresses the probe, or
rewrites the reply so that it does not carry the "STARTTLS" token,
makes a TLS-capable server appear not to support RPC-with-TLS, and
a client under an opportunistic policy proceeds in cleartext.
Nothing the client learns on the way to the server tells it that
TLS was expected.
[RFC9289] anticipated these problems and pointed at the same remedy
for them, DNS-Based Authentication of Named Entities (DANE)
[RFC6698], in several places:
* Section 1 lists DNSSEC/DANE among the platform facilities that
RPC-with-TLS support is assumed to build on.
* Section 6.1.1 offers a TLSA record as one of two mitigations for
STRIPTLS attacks: it "can alert clients that TLS is expected to
work, and provide a binding of a hostname to the X.509 identity",
and a client under an opportunistic security policy should check
for one before initiating an association. The other mitigation, a
policy that requires TLS on every connection, is strongly
encouraged where TLSA records are not available.
* Section 6.4 lists among its best security policy practices that,
when using AUTH_NULL or AUTH_SYS, "both peers are RECOMMENDED to
have DNSSEC TLSA records" together with "a security policy that
requires mutual peer authentication and rejection of a connection
when host authentication fails".
A TLSA RRset addresses both problems at once. Published in a zone
the operator already signs, it carries the binding between a server
name and its public key in the DNS, alongside the name the client had
to resolve anyway, so no client needs certification authority
material for that server. And because a DNSSEC-validated TLSA RRset
Lever Expires 5 April 2027 [Page 4]
Internet-Draft RPC TLS with DANE October 2026
is an authenticated statement by the server operator that TLS is
expected to work, a client holding one can no longer treat silent
fallback to cleartext as acceptable: the STRIPTLS attack fails
closed.
However, [RFC9289] offers a sketch rather than a specification. It
leaves unspecified the owner names at which a client queries for the
TLSA record, whether a lookup failure is treated as an absent record,
the name the client sends in SNI and verifies in the server's
certificate when a record is found, and which outcomes of the
AUTH_TLS probe still permit cleartext. Two independent
implementations resolving these questions differently would not
interoperate: one fails a handshake that the other completes. A
client that makes the permissive choice at each point obtains none of
the downgrade resistance a TLSA record appears to promise.
To close these gaps, this document specifies DANE for RPC-with-TLS
completely enough to implement and deploy, following the operational
specifications of [RFC7671] and [RFC7672] and making the RPC-specific
choices those documents leave to application protocols.
1.1. Scope
This document defines client behavior and changes nothing in the
protocol an RPC server implements. Its one requirement on the server
side, in Section 5.4, binds the publisher of the TLSA RRset.
Interoperation with a client implementing this document also depends
on two matters of server configuration that [RFC9289] does not
address: a server whose TLSA RRset is found through a CNAME alias has
to tolerate either of two Server Name Indication values, and a server
authenticated by a DANE-TA(2) record generally has to send the trust
anchor certificate. Appendix A.1 describes both.
This document specifies the use of DANE to authenticate an RPC server
to an RPC client. Authentication of an RPC client to an RPC server
by means of DANE is out of scope; see Section 13.7.
This document applies where the server authenticates itself with a
certificate. A server association that uses the pre-shared key
mechanism of Section 5.2.2 of [RFC9289] presents no certificate for
DANE to authenticate. The procedures in this document do not apply
to it. The exclusion extends to downgrade resistance: such an
association does not consult TLSA records to pin a security floor
(Section 9.1). The provisioned key is itself the operator's
commitment to TLS, and it is already in the client's possession, so
local policy can require TLS for the association without a DNS
lookup.
Lever Expires 5 April 2027 [Page 5]
Internet-Draft RPC TLS with DANE October 2026
Section 5.1 of [RFC7671] also provides for matching a DANE-EE(3)
record against a raw public key [RFC7250]; [RFC9289] defines no way
to convey one, so that case does not arise here.
TLSA owner names are defined here for the transports [RFC9289] itself
defines, namely TLS over TCP and DTLS over UDP. A future document
that specifies RPC over another transport is expected to define the
corresponding owner-name convention.
2. Updates to RFC 9289
Support for DANE remains optional for an RPC-with-TLS implementation.
The changes in this section bind a client that implements this
document; an implementation of [RFC9289] that does not is unaffected.
Two requirements of [RFC9289] are changed here:
* Section 5.2.1 of [RFC9289] requires PKIX path validation and a
check of the expected DNS-ID or iPAddress subjectAltName against
the presented certificate. Those requirements continue to apply
unchanged wherever this document requires PKIX authentication, and
to the name checks performed for certificate usage DANE-TA(2).
They do not apply to a server authenticated by a DANE-EE(3) match,
for the reasons given in Section 5.1 of [RFC7671] and restated in
Section 8.2.
* Where [RFC9289] cites [RFC6125] for certificate name checks,
clients implementing this document perform those checks per
[RFC9525], which obsoletes [RFC6125]. The additional restriction
in Section 5.2.1 of [RFC9289], that a DNS domain name in an RPC-
with-TLS certificate contain no wildcard character, is retained.
Elsewhere [RFC9289] makes a recommendation or leaves a choice to
local policy. This document replaces each of the following with a
requirement stated in the section named:
* The first bullet of Section 6.1.1 of [RFC9289] recommends a TLSA
check before an association is initiated, and disconnection when
TLS or authentication then fails. Section 7, Section 8.4, and
Section 9.1 replace that recommendation.
* The second bullet of Section 6.1.1 of [RFC9289] recommends a
policy that requires TLS on every connection, and Section 6.4
recommends, for AUTH_NULL and AUTH_SYS, TLSA records for both
peers and rejection of a connection when host authentication
fails. Section 9.1 and Section 9.3 require the server-
authentication half of that behavior where this document pins a
security floor; the client-authentication half is out of scope
Lever Expires 5 April 2027 [Page 6]
Internet-Draft RPC TLS with DANE October 2026
(Section 13.7). Where no floor is pinned, Section 9.3 permits
cleartext operation on a well-formed decline; a deployment that
adopts either recommendation in full remains conformant.
* Section 4.1 of [RFC9289] leaves to local policy whether RPC
operation continues in cleartext when the AUTH_TLS probe does not
yield the "STARTTLS" indication. Section 9.3 specifies that
policy, and it is more restrictive than what [RFC9289] permits.
This document also extends the audit log that Section 6.1 of
[RFC9289] requires: Section 11 adds to the required content of that
log and permits it to be assembled from correlatable events.
Nothing in this document changes the TLS version, ALPN, cipher suite,
confidentiality, or transport requirements of [RFC9289], nor its
provisions for pre-shared keys or for RPCSEC_GSS.
3. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document assumes a working knowledge of RPC version 2 [RFC5531],
of RPC-with-TLS [RFC9289], and of DANE [RFC6698] [RFC7671]. It uses
the DNSSEC validation states "secure", "insecure", and "bogus" as
defined in Section 5 of [RFC4033]. The definitions of
"indeterminate" in Section 5 of [RFC4033] and Section 4.3 of
[RFC4035] differ; this document classes a result that is
indeterminate in either sense as ERROR (Section 7.2).
The following terms are used as defined here.
Reference name: The DNS domain name that identifies to the client
the server it is contacting. For an association established by
administrative configuration, it is the name that appeared in that
configuration -- for NFS, the server component of the mount
specification. For a derived association (Section 10.3), it is
the name the upper-layer protocol supplied. Section 6 states the
requirements on it.
TLSA base domain: The domain name to which the port and transport
labels are prepended to form a TLSA owner name, as in Section 3 of
[RFC6698]. A client may have more than one candidate base domain
for a single reference name; see Section 7.3.
Lever Expires 5 April 2027 [Page 7]
Internet-Draft RPC TLS with DANE October 2026
Selected TLSA base domain: The candidate TLSA base domain at which
the client found a validated TLSA RRset. See Section 7.6.
DNS outcome class: One of the five results defined in Section 7.2
that a client assigns to a TLSA lookup for a given reference name,
port, and transport.
Usable record: A TLSA record that the client is able to use to
authenticate a server certificate, in the sense of Section 4.1 of
[RFC6698] and as further constrained by Section 7.5.
Server association: The set of transport connections a client
operates toward one server, selected by one reference name, and
treated as a single administrative and security unit; [RFC9289]
uses "association" informally. It begins with the client's first
association attempt and ends when the administrative action that
created it is undone. For NFS, it is what a mount point and any
additional connections established for it are carried over, and it
lasts from mount to unmount.
Association attempt: One attempt by a client to establish a
transport connection for a server association, from the selection
of a destination through either the completion of a TLS handshake,
a decision to proceed in cleartext, or failure.
Security floor: The minimum acceptable security level that a client
has determined for a server association, and below which it does
not operate. Section 9.1 states the requirement.
DANE policy mode: The client's configured disposition toward DANE
for a given server association: disabled, opportunistic, or
mandatory. See Section 4.1.
4. Overview of Operation
A client that has DANE enabled for a server association performs, in
addition to what [RFC9289] already specifies, the following steps.
1. It derives a reference name for the server it is about to
contact, subject to the requirements in Section 6. A destination
the client cannot name in the DNS, such as one selected by IP
address literal, carries no DANE binding and is handled per
Section 6.2.
2. It looks up TLSA records at the owner names derived from that
reference name, the destination port, and the transport, and
reduces the results to a single DNS outcome class. Section 7
specifies this procedure.
Lever Expires 5 April 2027 [Page 8]
Internet-Draft RPC TLS with DANE October 2026
3. It applies the outcome class to the association attempt. An
outcome of SECURE_USABLE or SECURE_UNUSABLE pins a security floor
for the association (Section 9.1), unless the port is of
untrusted provenance (Section 5.3). The floor constrains whether
cleartext operation remains permissible and which failures are
recoverable.
4. If a TLS handshake takes place, it authenticates the server
according to the outcome class: by DANE (Section 8) where the
client found a usable record, and by the PKIX rules of
Section 5.2.1 of [RFC9289] otherwise.
5. It records the policy inputs, the decision, and the
authentication result in the audit log that Section 6.1 of
[RFC9289] already requires (Section 11).
Steps 2 and 3 concern the association attempt as a whole and can be
performed before the AUTH_TLS probe is sent; step 4 happens during
the handshake. How an implementation divides the work is not
specified; Section 9.5 states the constraints that any division has
to respect.
4.1. DANE policy modes
A client implementing this document MUST support the following three
policy modes, and MUST allow the mode to be configured independently
for each server association.
Disabled: The client performs none of the procedures in this
document. Its behavior is that specified by [RFC9289].
Opportunistic: The client performs the procedures in this document.
A DNS outcome class of SECURE_USABLE or SECURE_UNUSABLE pins a
security floor, except where Section 5.3 withholds it, and
constrains the association as specified in Section 8.4 and
Section 9.1. SECURE_ABSENT and INSECURE do not pin a floor; a
floor pinned by an earlier attempt still governs the association,
and otherwise Section 9.3 governs whether the attempt may proceed
in cleartext. Any TLS session established is authenticated by the
PKIX rules of Section 5.2.1 of [RFC9289]. ERROR fails the attempt
(Section 8.4). This mode is intended for fleet-wide deployment
against a server population that has not uniformly published TLSA
records; see Appendix A.3.
Mandatory: The client performs the procedures in this document and
Lever Expires 5 April 2027 [Page 9]
Internet-Draft RPC TLS with DANE October 2026
additionally requires that the server be authenticated by DANE.
Any outcome other than SECURE_USABLE followed by a successful DANE
authentication MUST fail the association attempt. A destination
that cannot carry a DANE binding at all (Section 6.2) fails rather
than falling back to PKIX.
Mandatory mode never silently degrades. An implementation that lacks
some part of this specification, such as a transport for which it
defines no owner name, MUST fail an association attempt made in
mandatory mode rather than proceed without the protection the mode
was configured to obtain.
5. TLSA Records for RPC Services
5.1. Owner names
TLSA owner names for RPC services follow the convention in Section 3
of [RFC6698] without modification. The owner name is formed by
prepending, to a TLSA base domain:
* the second label "_tcp" for RPC-with-TLS over TCP, or "_udp" for
RPC-with-DTLS over UDP, per Sections 5.1.1 and 5.1.2 of [RFC9289];
and
* the first label, consisting of an underscore followed by the
decimal representation, without leading zeros, of the port number
to which the client connects.
For example, an NFS server reached at "nfs.example.com" on the
default NFS port over TCP publishes its TLSA RRset at
"_2049._tcp.nfs.example.com".
5.2. Alternate ports
The port in the owner name is the port to which the client actually
connects, not a registered port for the RPC program in use. RPC
services are routinely offered on other ports, by site convention or
by local configuration: a service reached on port 20490 over TCP at
"nfs.example.com" publishes its TLSA RRset at
"_20490._tcp.nfs.example.com", and a server that offers the same
service on several ports publishes one TLSA RRset per port.
Because the port is part of the owner name, a TLSA RRset
authenticates the server at a known port and says nothing about the
same server at another port, in the same way that Section 4.1 of
[RFC9289] observes that a successful AUTH_TLS probe on one port and
transport implies nothing about any other.
Lever Expires 5 April 2027 [Page 10]
Internet-Draft RPC TLS with DANE October 2026
5.3. Port provenance
The distinction that matters for downgrade resistance is not the
value of the port but where the client obtained it.
An RPC client may learn the port for a program from the server's
RPCBIND service [RFC1833], whose replies are not authenticated. An
attacker who substitutes a port in an RPCBIND reply thereby
substitutes the first label of the TLSA owner name the client will
query. The query is made at a name for which the operator published
nothing, and the client assigns SECURE_ABSENT (Section 7.2) and pins
no floor.
Accordingly:
* DANE authentication as specified in Section 8 applies at whatever
port the client connects to, whatever the provenance of that port.
* A client MUST NOT pin a security floor (Section 9.1) on the basis
of a DNS outcome derived from a port the client obtained from an
unauthenticated source. Ports obtained from local configuration,
including a configured default for the RPC program, are trusted
for this purpose; ports obtained from an unauthenticated RPCBIND
reply, or from any other unauthenticated in-band source, are not.
A TLSA RRset can authenticate a server at a port the client already
knew. It cannot retroactively secure the client's selection of that
port. Section 13.4 describes how a client obtains ports from an
authenticated source.
5.4. Publishing and key rollover
Publishers MUST observe the requirements of Section 8 of [RFC7671],
in particular during key rollover. Those requirements keep in the
RRset, at all times, a record matching the certificate that each
server answering for the name may present. A client that has pinned
a floor fails rather than falls back when the RRset and the
certificate disagree, so a rollover performed in the wrong order
takes the service down. That is intended, but operators need to plan
for it.
6. The Reference Name
6.1. Requirements on the reference name
The TLSA base domains a client considers MUST be derived from the
association's reference name, as specified in Section 7.
Lever Expires 5 April 2027 [Page 11]
Internet-Draft RPC TLS with DANE October 2026
A client MUST NOT use a name obtained by reverse resolution of the
server's network address as a reference name, or as the basis for
one. Such a name is chosen by whoever controls the reverse zone, and
accepting it would let that party select the TLSA RRset against which
the client authenticates.
Before treating a configured value as a reference name, a client MUST
apply the following input contract.
* If the value is an IPv4 or IPv6 address literal, including an IPv6
literal bearing a zone identifier, it is not a DNS name. The
destination carries no DANE binding; see Section 6.2.
* An internationalized domain name MUST be converted to A-label form
[RFC5890] before it is used to construct an owner name, as
Section 3 of [RFC6698] requires.
* The value MUST satisfy the syntax and length limits for DNS names
in [RFC1035], in both wire and presentation form. A value with an
empty or over-long label, or one that exceeds the total name
length limit once the port and transport labels have been
prepended, is not usable as a reference name, and the association
attempt is handled as in Section 6.2.
* ASCII case is not significant. A client that compares reference
names -- to decide whether two association attempts concern the
same server association, for instance -- MUST compare them case-
insensitively.
* A trailing empty label, written as a trailing dot in presentation
form, is retained when constructing DNS queries and removed when
the name is used as a Server Name Indication (SNI) value [RFC6066]
or as a PKIX reference identifier.
6.2. Destinations that carry no DANE binding
A destination selected by IP address literal has no DNS name from
which a TLSA base domain could be derived, and DANE does not apply to
it; this matches the treatment of address literals in Section 2.2 of
[RFC7672]. The same holds for a destination whose configured name
fails the input contract above.
For such a destination:
Lever Expires 5 April 2027 [Page 12]
Internet-Draft RPC TLS with DANE October 2026
* In opportunistic mode, the attempt does not pin a floor. If an
earlier attempt pinned one, that floor still governs the
association; otherwise Section 9.3 governs whether the attempt may
proceed in cleartext. If the client authenticates the server, it
does so by the rules of Section 5.2.1 of [RFC9289], which provide
for matching an iPAddress subjectAltName.
* In mandatory mode, the association attempt fails (Section 4.1).
7. Locating the TLSA RRset
7.1. Resolver trust
Every guarantee in this document rests on the client obtaining DNSSEC
validation states it can trust. A client that accepts the AD bit
from a remote validating resolver has moved its trust to that
resolver and to the path between them, which is precisely the kind of
unprotected path this document exists to defend against.
Accordingly, a client implementing this document MUST either validate
DNSSEC responses itself, or obtain them from a validating resolver it
trusts over an integrity-protected channel. A protected channel is
what Section 4.1 of [RFC6698] requires of a client that relies on
another entity for validation. A validating resolver on the same
host, reached without crossing a network, satisfies that requirement.
A client SHOULD validate DNSSEC responses itself.
Section 7.2 classes a failure to load, read, or parse the trust
anchors as ERROR, not INSECURE, since a client without them cannot
distinguish an unsigned zone from a signed one. An anchor maintained
automatically [RFC5011] that has fallen out of date is subject to the
same rule.
7.2. DNS outcome classes
A client reduces the result of its TLSA lookups for one reference
name, port, and transport to exactly one of the following five
outcome classes. Throughout, "usable" has the meaning given in
Section 7.5.
SECURE_USABLE: A DNSSEC-validated TLSA RRset was found, and at least
one record in it is usable. The client authenticates the server
by DANE.
SECURE_UNUSABLE: A DNSSEC-validated TLSA RRset was found, and no
record in it is usable. The operator has committed to TLS, but
the client cannot perform DANE authentication against what was
published.
Lever Expires 5 April 2027 [Page 13]
Internet-Draft RPC TLS with DANE October 2026
SECURE_ABSENT: The candidate base domains were exhausted without
finding a validated TLSA RRset, and the last candidate evaluated
yielded a DNSSEC-validated denial of existence. The operator has
published no signed TLSA RRset for this service.
INSECURE: The reference name itself lies in a provably unsigned span
of the DNS, or the search ended at a TLSA owner name that does.
DANE does not apply, and no conclusion can be drawn from the
absence or presence of records.
ERROR: The client could not obtain a validated answer. This class
covers a "bogus" or "indeterminate" validation result, a timeout,
a SERVFAIL or other error response, a malformed reply, a failure
to load, read, or parse the resolver's trust anchors, and any
other condition that prevents the client from assigning one of the
four classes above.
An ERROR outcome MUST NOT be treated as equivalent to INSECURE, and
MUST NOT authorize cleartext operation: as Sections 2.1.1 and 2.1.2
of [RFC7672] observe, the conditions that produce it are the ones an
attacker can produce at will. An implementation MAY retry a lookup
that produced ERROR; if no attempt yields a validated answer, the
outcome remains ERROR.
7.3. Candidate TLSA base domains
RPC-with-TLS has no service location indirection of the kind that MX
or SRV records provide, so the redirection case that Section 7 of
[RFC7671] addresses arises for RPC through CNAME aliasing. A client
therefore determines an ordered list of candidate base domains before
querying for TLSA records, as shown in Figure 1.
Lever Expires 5 April 2027 [Page 14]
Internet-Draft RPC TLS with DANE October 2026
CandidateBaseDomains(name):
Resolve the address records for "name" in each address family
the client will use for this association attempt, following
any CNAME chain hop by hop and noting the DNSSEC validation
state of each link.
If any step of that resolution is bogus or indeterminate, or
fails to complete:
return error
If the response for "name" itself, the first link of that
resolution, is insecure:
return insecure
If "name" is an alias, and in every address family resolved
the chain reaches the same canonical name, and every link of
every such chain is secure:
return [ canonical-name, name ]
return [ name ]
Figure 1: Determining the candidate base domains
The single-element result covers every case in which the client
cannot show that the redirection itself was authenticated. A client
MUST NOT expand a chain that it has not validated end to end, because
an unvalidated CNAME lets whoever forged it choose the base domain
and therefore the TLSA RRset.
The insecure result follows Section 2.2.2 of [RFC7672]. A reference
name in an unsigned zone is not expected to have a TLSA RRset that
validates, and some name servers for such zones mishandle TLSA
queries. Querying them would turn a destination to which DANE does
not apply into an ERROR, so the client makes no TLSA query and
assigns INSECURE.
A CNAME encountered at a TLSA owner name itself is followed by
ordinary DNS resolution under the same requirement; a chain with an
insecure or bogus link yields INSECURE or ERROR respectively for that
candidate. Such a CNAME does not change which candidate is the
selected TLSA base domain, since it redirects the records, not the
identity of the service.
7.4. Evaluation and result reduction
A client evaluates the candidate list in order, as shown in Figure 2.
Lever Expires 5 April 2027 [Page 15]
Internet-Draft RPC TLS with DANE October 2026
Evaluate(refname, port, proto):
name = Normalize(refname) ; input contract
if name is an address literal or fails the contract:
return "no DANE binding" ; no outcome class
candidates = CandidateBaseDomains(name) ; preceding figure
if candidates is error:
return ERROR
if candidates is insecure:
return INSECURE ; no TLSA query
for C in candidates: ; in order
owner = "_" + port + "._" + proto + "." + C
R = Lookup(owner, TLSA)
if R is bogus or indeterminate or failed:
return ERROR
if R is secure and carries a TLSA RRset:
selected_base_domain = C
if AnyUsable(R): ; usability filtering
return SECURE_USABLE
else:
return SECURE_UNUSABLE
if R is secure and is a denial of existence:
continue
if R is insecure:
if C is not the last candidate:
continue
else:
return INSECURE
return SECURE_ABSENT
Figure 2: TLSA lookup and result reduction
The rules this encodes, stated in prose:
* A validated TLSA RRset is final, whether or not the client can use
the records in it. Finding one stops the search; the client does
not fall back to a later candidate in the hope of finding records
it likes better. This is what makes SECURE_UNUSABLE a distinct
outcome rather than a variety of absence.
Lever Expires 5 April 2027 [Page 16]
Internet-Draft RPC TLS with DANE October 2026
* A validated denial of existence continues the search, per
Section 7 of [RFC7671], which directs a client that finds no TLSA
record at the expanded name to query at the original name. If no
candidate remains, the outcome is SECURE_ABSENT. An insecure
answer likewise continues the search, since the operator may have
published a signed RRset at a later candidate.
A client MUST assign the same outcome class as this procedure would
for the same DNS data. Implementations are not required to perform
the queries in this order, or to perform queries whose result cannot
affect the outcome.
7.5. Usable records and digest algorithm agility
Whether a record is usable is determined before any attempt is made
to match it against a certificate, and a record that is usable but
does not match the server's certificate is an authentication failure,
never a reason to reclassify the RRset as unusable. Conflating the
two would let an attacker who can influence the certificate a server
presents convert a DANE mismatch into a fallback.
A client determines the usable records in a validated TLSA RRset as
follows.
1. Discard any record whose RDATA is truncated, whose certificate
association data has a length inconsistent with its matching
type, or that is otherwise malformed.
2. Discard any record whose certificate usage, selector, or matching
type the client has not implemented or has been configured not to
use. Certificate usage support is specified in Section 8.1.
3. Apply digest algorithm agility per Section 9 of [RFC7671]: for
each combination of certificate usage and selector remaining, the
client retains records with a matching type of Full(0), and
records whose matching type is the strongest the client supports
among those present for that usage and selector. Records using a
weaker supported matching type are discarded.
A matching type the client does not support MUST NOT suppress the
strongest type it does support, and malformed records MUST be
discarded in step 1 so that they do not influence the strength
selection in step 3.
Lever Expires 5 April 2027 [Page 17]
Internet-Draft RPC TLS with DANE October 2026
If any record survives step 2, the RRset is usable and the outcome is
SECURE_USABLE. If none does, the RRset is unusable and the outcome
is SECURE_UNUSABLE. Step 3 narrows the records the client matches
against, but it never discards the last record for a usage and
selector, so it cannot change the outcome class.
7.6. The selected TLSA base domain, SNI, and reference identifiers
The selected TLSA base domain is the candidate at which the
evaluation in Section 7.4 found a validated TLSA RRset. It is
defined only for the outcome classes SECURE_USABLE and
SECURE_UNUSABLE.
When the outcome is SECURE_USABLE, the selected TLSA base domain MUST
be sent as the Server Name Indication [RFC6066] value and, for
certificate usages other than DANE-EE(3), MUST be the primary
reference identifier for certificate name checks. This is the rule
of Section 7 of [RFC7671].
When the outcome is SECURE_UNUSABLE, the client MUST instead send the
original reference name as the Server Name Indication value, and MUST
use the original reference name as the reference identifier for the
PKIX name checks that Section 8.4 then requires.
This departs from Section 7 of [RFC7671] because of what
SECURE_UNUSABLE means. A DANE client puts the expanded base domain
in SNI because it is prepared to accept a certificate issued for that
name. A client that can use no record in the RRset is about to fall
back to PKIX authentication against the configured name; sending the
base domain in SNI would ask a server that selects its certificate by
SNI for a certificate the client must then reject, and the handshake
fails for a reason unrelated to the security of either name.
The selected TLSA base domain is reported in the audit record
(Section 11) in both cases, so that an operator can see which name
the policy decision was derived from.
8. Authenticating the Server
8.1. Certificate usages
A client implementing this document MUST support certificate usages
DANE-EE(3) and DANE-TA(2). Both are used with the semantics given in
Sections 5.1 and 5.2 of [RFC7671] respectively. Section 4 of
[RFC7671] recommends exactly this pair, and cautions that
simultaneous support for all four usages is not recommended.
Lever Expires 5 April 2027 [Page 18]
Internet-Draft RPC TLS with DANE October 2026
Support for certificate usages PKIX-TA(0) and PKIX-EE(1) is OPTIONAL.
A client that does not support them treats records carrying them as
unusable in step 2 of Section 7.5. Where such records are the only
ones published, the outcome is SECURE_UNUSABLE, and Section 8.4
requires the client to authenticate the server by the PKIX rules of
Section 5.2.1 of [RFC9289]. That check is weaker than the published
records call for, but never weaker than [RFC9289] alone.
A client MUST support the selectors Cert(0) and SPKI(1) and the
matching types Full(0) and SHA2-256(1), which is the support that
Section 6 of [RFC6698] lets publishers rely on. Support for
SHA2-512(2) is RECOMMENDED.
8.2. DANE-EE(3)
Authentication by a DANE-EE(3) record consists of matching the
server's end-entity certificate, or its SubjectPublicKeyInfo, against
the certificate association data of a usable record, per Section 5.1
of [RFC7671].
When such a match succeeds, the server is authenticated. In
particular, and following Section 5.1 of [RFC7671]:
* The client MUST NOT reject the server because no name in the
presented certificate matches the reference name or the selected
TLSA base domain. The binding of key to name is made by the TLSA
record, not by the certificate.
* The client MUST NOT reject the server because the presented
certificate is expired or not yet valid. The validity of the
binding is the validity of the DNSSEC signatures over the TLSA
RRset.
* The client MUST NOT require that the presented certificate chain
to a trusted certification authority.
Consequently a self-signed server certificate, published as a DANE-
EE(3) record with selector SPKI(1) and matching type SHA2-256(1), is
a fully conforming deployment; see Appendix A.1.
8.3. DANE-TA(2)
Authentication by a DANE-TA(2) record consists of validating the
server's certificate chain to the trust anchor the record identifies,
per Section 5.2 of [RFC7671], and then performing name checks against
the reference identifiers determined in Section 7.6.
Lever Expires 5 April 2027 [Page 19]
Internet-Draft RPC TLS with DANE October 2026
Those name checks are performed per [RFC9525], retaining the
restriction in Section 5.2.1 of [RFC9289] that a DNS domain name in
an RPC-with-TLS certificate MUST NOT contain the wildcard character
"*".
8.4. Required client behavior by outcome class
Table 1 states what a client in opportunistic mode MUST do for each
DNS outcome class. In mandatory mode the SECURE_USABLE row applies,
with TLS required whatever the provenance of the port, and every
other outcome fails the association attempt (Section 4.1). In every
case where authentication is required, failure of that authentication
fails the association attempt; see Section 9.4.
The requirement that TLS be used is carried by the security floor.
Where the DNS outcome was derived from a port of untrusted
provenance, Section 5.3 withholds that floor, and in opportunistic
mode Section 9.3 then governs whether the attempt may proceed in
cleartext. The authentication requirements in the table apply to any
(D)TLS session that is established, whatever the provenance of the
port.
+=================+================================================+
| DNS outcome | Opportunistic mode |
+=================+================================================+
| SECURE_USABLE | TLS is required, and the server MUST be |
| | authenticated by DANE per Section 8. PKIX |
| | authentication MUST NOT be substituted for it. |
+-----------------+------------------------------------------------+
| SECURE_UNUSABLE | TLS is required, and the server MUST be |
| | authenticated per Section 5.2.1 of [RFC9289]. |
+-----------------+------------------------------------------------+
| SECURE_ABSENT | This outcome does not pin a floor. A floor |
| | pinned by an earlier attempt still governs the |
| | association; otherwise Section 9.3 governs |
| | cleartext operation. A TLS session is |
| | authenticated per Section 5.2.1 of [RFC9289]. |
+-----------------+------------------------------------------------+
| INSECURE | As for SECURE_ABSENT. |
+-----------------+------------------------------------------------+
| ERROR | The attempt MUST fail. |
+-----------------+------------------------------------------------+
Table 1: Required client behavior by DNS outcome class
The SECURE_USABLE row is the central requirement of this document. A
client MUST NOT accept a PKIX authentication in place of the DANE
authentication the RRset calls for, however trusted the issuing
Lever Expires 5 April 2027 [Page 20]
Internet-Draft RPC TLS with DANE October 2026
certification authority; that substitution would return control of
the association's authentication to whoever can obtain a certificate
for the name, which is what the TLSA RRset was published to prevent.
The SECURE_UNUSABLE row strengthens the guidance in Section 10.3 of
[RFC7671] and Section 2.2 of [RFC7672], which require only
unauthenticated TLS in this case; Section 10.3 of [RFC7671]
anticipates such a strengthening where expecting it is realistic for
the application protocol. For RPC-with-TLS the intermediate position
is not available at all. In both client deployment modes of
Section 4.2 of [RFC9289] the server presents an identity that the
client can authenticate, and Section 5.2.1 of [RFC9289] states what
validation of the server's certificate MUST include, so accepting
unauthenticated TLS here would be a downgrade relative to the base
specification rather than an improvement on cleartext.
9. Downgrade Resistance
9.1. The security floor
A DNS outcome class of SECURE_USABLE or SECURE_UNUSABLE pins a
security floor for the server association, except where Section 5.3
withholds it: the client MUST NOT operate that association at a
security level weaker than an authenticated TLS session, and MUST
fail the association attempt rather than do so.
The floor is a property of the server association, not of the
connection on which it was determined, and it persists for the
lifetime of the association. Once pinned, it applies to every
subsequent association attempt for that association and to every
transport that joins it (Section 10). A later evaluation whose
outcome class does not pin a floor does not remove one already
pinned: an operator who withdraws a TLSA RRset lowers the floor only
for associations established after the withdrawal (Appendix A.1). A
client MUST retain a pinned floor, together with the selected TLSA
base domain it was derived from, until the association ends.
The floor is stated in terms of the security level reached rather
than of any particular attack. It covers the STRIPTLS attack of
Section 6.1.1 of [RFC9289], to which Section 9.2 specifies the
client's response, and any mechanism by which an attacker induces a
client to select a transport or path that receives weaker protection;
a document specifying RPC over another transport can cite this
section for the latter.
Lever Expires 5 April 2027 [Page 21]
Internet-Draft RPC TLS with DANE October 2026
9.2. AUTH_TLS probe outcomes
Section 4.1 of [RFC9289] specifies that a client that does not
receive the "STARTTLS" indication MUST NOT send a ClientHello, and
that "RPC operation may continue, depending on local policy, but
without confidentiality, integrity, or peer authentication protection
from (D)TLS". This document specifies that local policy.
A client classifies the result of the AUTH_TLS probe into exactly one
of the following outcomes.
ACCEPTED: A Reply was received with a reply_stat of MSG_ACCEPTED and
an AUTH_NONE verifier containing the "STARTTLS" token, as
specified in Section 4.1 of [RFC9289].
DECLINED: A complete, well-formed Reply to the probe was received
that indicates the server does not support RPC-with-TLS. This
comprises a reply_stat of MSG_ACCEPTED with an AUTH_NONE verifier
that does not carry the "STARTTLS" token, and a reply_stat of
MSG_DENIED with a reject_stat of AUTH_ERROR. These are the
responses produced by a server that does not implement the
AUTH_TLS authentication flavor; in particular, AUTH_ERROR is how a
server predating [RFC9289] rejects an unrecognized flavor.
RPCERR: A complete, well-formed Reply was received that is neither
of the above -- for example a reply_stat of MSG_DENIED with a
reject_stat of RPC_MISMATCH, or a reply_stat of MSG_ACCEPTED with
a verifier whose flavor is not AUTH_NONE.
MALFORMED: A response was received that cannot be parsed as a well-
formed RPC Reply to the probe, or whose verifier length is
inconsistent with its declared flavor.
UNREACHABLE: The connection was refused or reset, or was closed
before a Reply was received.
TIMEOUT: No response was received within the client's timeout.
LOCAL: A local resource failure prevented the probe from being sent,
or its result from being determined.
9.3. Cleartext fallback
Table 2 states whether a client in opportunistic mode may continue in
cleartext. A client in mandatory mode never does. Any probe outcome
other than ACCEPTED fails the association attempt (Section 4.1).
Lever Expires 5 April 2027 [Page 22]
Internet-Draft RPC TLS with DANE October 2026
+==========+================+===================================+
| Probe | Floor pinned | No floor pinned |
| outcome | | |
+==========+================+===================================+
| ACCEPTED | Proceed to the | Proceed to the TLS handshake. |
| | TLS handshake. | |
+----------+----------------+-----------------------------------+
| DECLINED | The attempt | Cleartext operation is permitted, |
| | MUST fail. | subject to local policy, per |
| | | Section 4.1 of [RFC9289]. |
+----------+----------------+-----------------------------------+
| Any | The attempt | The attempt MUST fail. |
| other | MUST fail. | |
+----------+----------------+-----------------------------------+
Table 2: Cleartext fallback by AUTH_TLS probe outcome
Only DECLINED permits cleartext operation, and only where no floor
has been pinned. The other non-ACCEPTED outcomes are what an
attacker interfering with the cleartext exchange looks like; a client
that treats them as declines has no downgrade resistance even against
an attacker who cannot forge a well-formed Reply.
[[TODO: Whether opportunistic mode should instead take the stricter
policy of Section 6.1.1 and Section 6.4 of [RFC9289], at the cost of
reachability to servers that predate it, is open.
https://github.com/chucklever/i-d-rpc-tls-dane/issues/4 ]]
9.4. Failure after a handshake is attempted
Once the AUTH_TLS probe has been ACCEPTED and a (D)TLS handshake has
been attempted, the client MUST NOT retry the association attempt in
cleartext, whatever the DNS outcome class and whatever the reason the
handshake or the subsequent authentication failed. This holds for
DANE mismatches, PKIX validation failures where PKIX applies, TLS
negotiation failures, and the unavailability of whatever local
component performs the handshake.
Section 4.1 of [RFC9289] describes a client that reports a handshake
failure after a successful probe the same way it reports an
AUTH_ERROR rejection; a client implementing this document MUST report
it that way.
Lever Expires 5 April 2027 [Page 23]
Internet-Draft RPC TLS with DANE October 2026
9.5. Coherence within an association attempt
How an implementation obtains DNS data, how many times within one
association attempt it evaluates Section 7, and how a policy result
reaches the point at which the handshake is authenticated are
implementation matters. Two properties are required of any
arrangement.
* A client MUST evaluate the DNS outcome class from DNS data that is
current at the time of the association attempt, and MUST NOT reuse
an outcome obtained for an earlier attempt beyond the TTL of the
DNS data it was derived from. The security floor is not such a
result: it persists across attempts (Section 9.1), and a fresh
evaluation can pin a floor or leave one in place but never remove
it.
* Within one association attempt, a client MUST NOT conclude at a
security level weaker than any determination it has already made
during that attempt. Where two evaluations during one attempt
disagree, the stronger conclusion governs.
The second property is what makes the mechanism resistant to an
attacker who can affect the timing of DNS answers. Under it,
SECURE_USABLE is stronger than SECURE_UNUSABLE, and SECURE_UNUSABLE
is stronger than SECURE_ABSENT and INSECURE, which are equal to each
other. An evaluation whose outcome is ERROR fails the attempt
(Section 8.4) and takes no part in the ordering. The stronger
conclusion governs regardless of which evaluation produced it, so a
later evaluation that finds a usable RRset where an earlier one did
not replaces the earlier conclusion.
The second property orders outcome classes, not the contents of two
RRsets. Where two evaluations during one attempt both yield
SECURE_USABLE and their usable records differ, the client MUST
authenticate the server against the usable records of one of those
evaluations as a whole, and MUST NOT combine records drawn from
different evaluations. A TLSA RRset republished mid-attempt during a
key rollover produces this case; when the publisher has observed
Section 5.4, both RRsets match the certificate the server presents
and the attempt succeeds whichever one the client uses.
10. Association Scope and Policy Granularity
Lever Expires 5 April 2027 [Page 24]
Internet-Draft RPC TLS with DANE October 2026
10.1. Policy is per association
The DANE policy mode, the reference name, and any pinned security
floor are properties of a server association. A client MUST be able
to apply different policies concurrently to different server
associations, since the servers a host contacts differ in whether
they have deployed DANE.
A client that shares underlying state between server associations --
connection caching, session reuse, or a client object shared between
two mounts of the same server -- MUST NOT share it between
associations whose DANE policy modes or reference names differ. Two
names that resolve to the same address may have different TLSA
RRsets, and an association established under one name has not
authenticated the server for the other.
10.2. Transports joining an association later
A client may add transports to an existing server association for
additional bandwidth or additional server network paths.
While a security floor is pinned for an association, a transport MUST
NOT join that association unless it carries the association's
reference name and is established with the authenticated TLS session
the floor requires. A transport whose destination is an address
literal therefore cannot join a floor-pinned association
(Section 6.2). A client MUST refuse an addition that does not meet
both conditions and record the refusal (Section 11); the association
continues over the transports that do meet its floor.
10.3. Derived associations
Upper-layer protocols direct clients to establish further
associations to destinations the client did not select. NFSv4
[RFC8881] does this in at least three ways: a parallel NFS layout
identifies data servers, the file system location attributes identify
referral targets, and a migration event identifies a new location for
a file system. A destination so identified is either an address
literal or a DNS name. A name is the reference name of the derived
association, subject to the input contract of Section 6; an address
literal gives the derived association no DANE binding (Section 6.2).
Lever Expires 5 April 2027 [Page 25]
Internet-Draft RPC TLS with DANE October 2026
A security floor pinned for one server association does not extend to
a derived association. A client MUST evaluate DANE policy
independently for each association it establishes, from that
association's own reference name. In mandatory mode, a derived
association for which no DANE binding can be established fails
(Section 4.1), even though this may render some upper-layer features
unusable (Section 13.5).
Defining DNS-based identities for the destinations that upper-layer
protocols hand out -- so that a data server or a referral target can
be named rather than addressed -- is work for the specifications of
those protocols, and is outside the scope of this document.
11. Auditing
A client implementing this document MUST extend the audit log that
Section 6.1 of [RFC9289] requires to cover the DANE policy decision.
For each association attempt in which DANE policy applied, the record
MUST include:
* the reference name, and an indication of whether it was supplied
by local configuration or derived some other way;
* the destination network address, port, and transport;
* the DANE policy mode in effect and where it came from;
* the DNS outcome class, with enough diagnostic detail to
distinguish the conditions grouped under ERROR, or an indication
that no lookup was made because the destination carries no DANE
binding (Section 6.2);
* the selected TLSA base domain, where one was determined;
* the AUTH_TLS probe outcome (Section 9.2), or an indication that
the attempt failed before a probe was sent;
* the means by which the server was authenticated, if it was: DANE-
EE(3), DANE-TA(2), or PKIX;
* for a DANE authentication, the usage, selector, and matching type
of the record that matched; and
* the resulting disposition of the attempt: authenticated TLS,
cleartext operation, or failure, with the reason for a failure.
Lever Expires 5 April 2027 [Page 26]
Internet-Draft RPC TLS with DANE October 2026
The record MAY consist of correlatable events emitted by more than
one component, provided that the events can be joined and that
together they cover the whole list.
12. Implementation Status
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
12.1. tlshd (ktls-utils)
Organization: The ktls-utils project.
Description: tlshd is the userspace handshake agent used by the
Linux kernel's TLS handshake service. It performs the (D)TLS
handshake on behalf of in-kernel RPC-with-TLS consumers.
Implementation: https://github.com/linux-nfs/ktls-utils
Level of maturity: Prototype. The DANE support first shipped in
ktls-utils 1.5.0, and is disabled by default.
Coverage: The reference-name input contract (Section 6); the
candidate determination and result reduction of Section 7,
including secure CNAME expansion; the five outcome classes of
Section 7.2; the usability filtering and digest algorithm agility
of Section 7.5; the reference-identity rules of Section 7.6;
certificate usage DANE-EE(3) (Section 8.2); and the authentication
behavior of Section 8.4 for both the client-anonymous and the
mutually authenticated handshake path.
Not implemented: certificate usage DANE-TA(2), DTLS over UDP, and
the association-scope enforcement of Section 10, which belongs to
the RPC client rather than to the handshake agent.
Licensing: GPLv2.
Lever Expires 5 April 2027 [Page 27]
Internet-Draft RPC TLS with DANE October 2026
Contact: The editor of this document.
Experience: The implementation was exercised against publicly
available DANE test zones as well as against a locally signed test
zone. The reference-identity rule in Section 7.6 for the
SECURE_UNUSABLE class was added after the implementation hit the
handshake failure that section describes.
13. Security Considerations
The security considerations of [RFC9289], [RFC6698], [RFC7671], and
[RFC4033] apply.
13.1. What DANE authentication does and does not establish
A successful DANE-EE(3) match establishes that the peer holds the key
that the operator of the TLSA base domain's zone published for that
service at that port and transport. It establishes nothing about the
names in the presented certificate, its validity dates, or its issuer
(Section 8.2). A deployment that relies on certificate contents for
authorization -- an extended key usage check, a certificate policy, a
subjectAltName URI -- as Section 5.2.1 of [RFC9289] permits, needs to
keep performing those checks independently; a DANE match does not
perform them.
Control of the zone that publishes the TLSA RRset is control of the
service's authentication. Trust moves from the certification
authorities the client would otherwise trust to the zone operator and
the DNSSEC chain above it. For the deployments in Appendix A.1 that
is the point, since the party that operates the server also operates
the zone; where DNS is operated by a third party, the concentration
should be evaluated before deployment.
13.2. Replay and the limits of revocation
DNSSEC provides no way to revoke a signed RRset before its signatures
expire (Section 11 of [RFC7671]). The following consequences are
each bounded by a signature validity period rather than by anything
the client can do.
An attacker who captured a signed denial of existence for a TLSA
owner name before the operator published the RRset can replay it
within that period; the client assigns SECURE_ABSENT and does not pin
a floor (Appendix A.3).
An attacker who captured the parent zone's signed proof that the
operator's zone has no DS RRset, before the operator signed that
zone, can replay it in the same way. A validator shown that proof
Lever Expires 5 April 2027 [Page 28]
Internet-Draft RPC TLS with DANE October 2026
treats the zone as unsigned (Section 5.2 of [RFC4035]); the client
assigns INSECURE and does not pin a floor. The window is bounded by
the validity period of the parent zone's signatures, which the
operator of the service does not choose.
An attacker who holds a key the operator has withdrawn can replay the
TLSA RRset that still names it, and a client will authenticate the
peer; since Section 8.2 disregards the certificate's validity dates,
the RRset's signatures are the only expiry. The mitigation is
operational and belongs to the publisher (Appendix A.1).
A security floor, once pinned, persists for the lifetime of the
association (Section 9.1). A replayed denial therefore cannot
authorize cleartext operation once a floor is pinned: replayed at a
reconnect, it leaves the floor in place, and a forged decline fails
the attempt rather than permitting fallback.
That guarantee has two limits. An association whose attempts have so
far pinned no floor stays exposed to the replay at every later
attempt, until an evaluation pins one. And the floor requires an
authenticated TLS session, not DANE authentication. An attempt that
a replayed denial leaves at SECURE_ABSENT or INSECURE authenticates
the server by the PKIX rules of Section 5.2.1 of [RFC9289], so within
the replay window an attacker who can present a certificate those
rules accept regains the substitution that Section 8.4 forbids for
SECURE_USABLE. Where the client trusts no certification authority
that would issue such a certificate, as in the deployment
Appendix A.1 describes, the attempt fails.
Conversely, this document does not require a client to re-evaluate an
association that is already established, so a long-lived session
established against an RRset that has since been withdrawn continues
under the conclusion reached when it was established.
13.3. Fail-closed behavior is a denial-of-service surface
The rules in Section 8.4, Section 9.3, and Section 9.5 require a
client to fail an association attempt in circumstances where an
[RFC9289] client would have continued. An attacker who can disrupt
the client's DNS -- by dropping responses, by inducing SERVFAIL, or
by corrupting signatures to produce a bogus validation result -- can
therefore prevent the client from establishing associations. The
exposure extends to an association already established: each
reconnection is an association attempt and evaluates the DNS outcome
afresh (Section 9.5), so a disruption of DNS that coincides with the
loss of a connection keeps the association from recovering.
Lever Expires 5 April 2027 [Page 29]
Internet-Draft RPC TLS with DANE October 2026
This is a deliberate trade: degrading when DNS is disrupted hands the
same attacker the ability to strip protection silently, and an
attacker who can disrupt DNS can usually disrupt the RPC traffic
itself. Opportunistic mode does not relieve this exposure, since
ERROR fails the attempt in both active modes; operators for whom
availability outweighs confidentiality express that by leaving DANE
disabled for the associations concerned.
13.4. Unauthenticated port selection
The rule in Section 5.3, that a floor is pinned only on a port of
trusted provenance, keeps an attacker who substitutes the port in an
RPCBIND [RFC1833] reply from pinning a floor the operator did not
intend. It does not prevent the SECURE_ABSENT outcome that the
substitution produces, so a client that obtains its ports from
RPCBIND is left as exposed to cleartext fallback as an [RFC9289]
client.
An RPCBIND reply carries a universal address (Section 2.2.1 of
[RFC1833]), so an attacker who rewrites it can substitute the host as
readily as the port. A substituted host alone is defended by DANE,
since it cannot present a certificate matching the TLSA RRset for the
reference name; a substituted port yields SECURE_ABSENT, and neither
the address nor the port is then protected.
The remedy available today is to protect RPCBIND itself. RPCBIND is
an RPC program, so a client can send an AUTH_TLS probe to its port,
authenticate it by the procedures in this document against the TLSA
RRset published for that port and transport, and make its lookups
over the resulting session. The ports it learns then come from an
authenticated source. The RPCBIND port is well known and therefore
of trusted provenance under Section 5.3, so there is no bootstrap
problem. This document describes the arrangement rather than
requiring it, since no RPCBIND implementation is known to support
RPC-with-TLS.
A session established to the RPCBIND port authenticates the RPCBIND
service alone. The service the client goes on to contact is
authenticated separately, against the TLSA RRset for its own port,
and a security floor determined for one is not a floor for the other.
An operator who protects RPCBIND but publishes no TLSA RRset for the
service has secured the discovery step alone; one who publishes for
the service but leaves RPCBIND unprotected has left the guarantees in
this document resting on an unauthenticated reply.
Lever Expires 5 April 2027 [Page 30]
Internet-Draft RPC TLS with DANE October 2026
13.5. Derived associations
A security floor does not extend to an association whose destination
an upper-layer protocol supplied (Section 10.3). The practical
consequence for NFSv4 [RFC8881] is that data-path traffic is
protected only as well as the weakest derived association carrying
it. A client that has pinned a floor for its metadata association,
and then reads and writes file data over parallel NFS data server
connections established from address literals, has obtained no DANE
protection for the data itself. Operators should not infer from a
floor pinned on the metadata association that the data path is
equivalently protected. A client in mandatory mode fails such
connections rather than establishing them (Section 10.3), which makes
the limitation visible rather than silent, at the cost of the
feature.
13.6. Privacy considerations
TLSA queries disclose, to an observer of the client's DNS traffic,
which RPC services the client is about to contact and on which ports.
The names and addresses are already disclosed by address resolution
and by the RPC traffic itself; the port and transport labels are
additional. This disclosure happens before the exchanges that
Section 6.1.2 of [RFC9289] discusses, and the precautions given there
do not reach it.
[RFC9076] surveys what DNS transactions disclose. Two mitigations
are available, and each is partial. An encrypted transport to the
resolver (Section 5.2 of [RFC9076]) hides the queries from an
observer of that path, but not from the resolver. Resolving
recursively on the client removes the third-party resolver, but
exposes the client's address to the authoritative servers it queries
(Section 6.2 of [RFC9076]). Pervasive monitoring [RFC7258] of DNS is
a known concern for DANE generally.
13.7. Client authentication
This document specifies the authentication of a server to a client
only. [RFC9289] also provides for mutual authentication, in which
the server validates the client's certificate by PKIX; DANE-based
authentication in that direction is not specified here. The generic
mechanism exists in [I-D.ietf-dance-client-auth], and an RPC profile
of it would need to choose the owner-name form for RPC peers,
restrict the certificate usages, and specify how a DANE-authenticated
client name maps onto RPC-layer authorization. That is work for a
separate document.
Lever Expires 5 April 2027 [Page 31]
Internet-Draft RPC TLS with DANE October 2026
Until then, a deployment that requires mutual authentication uses the
PKIX mechanism of Section 5.2.1 of [RFC9289] for the client direction
and DANE for the server direction; Section 8.4 applies to the
server's certificate whether or not the client presents one.
14. IANA Considerations
This document requests no IANA actions.
15. References
15.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/rfc/rfc5531>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/rfc/rfc6066>.
Lever Expires 5 April 2027 [Page 32]
Internet-Draft RPC TLS with DANE October 2026
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9289] Myklebust, T. and C. Lever, Ed., "Towards Remote Procedure
Call Encryption by Default", RFC 9289,
DOI 10.17487/RFC9289, September 2022,
<https://www.rfc-editor.org/rfc/rfc9289>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
15.2. Informative References
[I-D.ietf-dance-client-auth]
Huque, S. and V. Dukhovni, "TLS Client Authentication via
DANE TLSA records", Work in Progress, Internet-Draft,
draft-ietf-dance-client-auth-14, 11 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dance-
client-auth-14>.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, DOI 10.17487/RFC1833, August 1995,
<https://www.rfc-editor.org/rfc/rfc1833>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/rfc/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.
Lever Expires 5 April 2027 [Page 33]
Internet-Draft RPC TLS with DANE October 2026
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/rfc/rfc7435>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015,
<https://www.rfc-editor.org/rfc/rfc7672>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS)
Version 4 Minor Version 1 Protocol", RFC 8881,
DOI 10.17487/RFC8881, August 2020,
<https://www.rfc-editor.org/rfc/rfc8881>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/rfc/rfc9076>.
Appendix A. Deployment Considerations
Lever Expires 5 April 2027 [Page 34]
Internet-Draft RPC TLS with DANE October 2026
A.1. Publishing TLSA records for RPC services
The simplest conforming deployment, and the one that addresses the
operational problem described in Section 1, is to publish for each
service a single DANE-EE(3) record with selector SPKI(1) and matching
type SHA2-256(1), written "3 1 1", in a DNSSEC-signed zone:
_2049._tcp.nfs.example.com. IN TLSA 3 1 1 (
2A1B4C... )
Figure 3: A minimal TLSA RRset for an NFS service
Clients then need no certification authority material for those
servers, the operator maintains the binding in one place, and by
Section 8.2 the certificate may be self-signed with any notAfter
date. Keeping the RRset and certificates in step, in particular
during key rollover, is specified in Section 5.4. Withdrawing DANE
takes the same posture: a client that has pinned a floor for an
association keeps requiring authenticated TLS until that association
ends (Section 9.1), so removing the RRset lowers what clients require
only as they remount. Where clients hold no certification authority
material for the server, an association with a pinned floor cannot
re-establish a connection once the RRset is gone: the floor still
requires an authenticated session, and nothing remains to
authenticate it against.
The signature validity period the operator chooses bounds the replay
windows described in Section 13.2, except that of a replayed proof of
an unsigned delegation, which the parent zone's signatures bound.
Section 11 of [RFC7671] suggests a lifetime of a few days for domains
publishing high-value keys.
A publisher of DANE-TA(2) records has one further obligation. A
client validates the server's chain to the trust anchor the record
identifies (Section 8.3), and it has no trust store in which to find
that anchor. Unless the record carries the full trust anchor
certificate, the server therefore has to include the anchor in the
chain it presents, even a self-signed root that a TLS server would
ordinarily omit; Section 5.2.2 of [RFC7671] states the requirement.
The Server Name Indication value such a deployment receives is not
fixed. Section 7.6 sends the selected TLSA base domain when the
outcome is SECURE_USABLE and the original reference name when it is
SECURE_UNUSABLE, and the two differ whenever the RRset was found at a
securely CNAME-expanded name. A server that selects its certificate
strictly by SNI, and fails a handshake carrying a name it does not
recognize, rejects clients that conform to this document. A server
should instead present its default certificate, the one its TLSA
Lever Expires 5 April 2027 [Page 35]
Internet-Draft RPC TLS with DANE October 2026
RRset matches, when the SNI value is absent or unrecognized.
Section 8.1 of [RFC7672] gives SMTP servers the same guidance for the
same reason.
A.2. Unsigned zones prove nothing
A TLSA RRset in an unsigned zone yields the outcome INSECURE whatever
it contains, and so does a denial of existence from one. Publishing
without signing the zone gives an attacker something to remove rather
than the client something to rely on; an operator obtains none of the
properties in this document without signing the zone.
A.3. Downgrade resistance of opportunistic DANE
Opportunistic mode (Section 4.1) adapts to what each operator has
deployed, which is what makes it usable across a mixed server
population. This adaptivity is not itself a downgrade path.
Against a client that validates DNSSEC, moving a server from
SECURE_USABLE to a weaker class requires forging a denial of
existence in a signed zone, which fails validation; stripping
signatures, which yields ERROR and fails the attempt; or a validated
proof that a delegation above the owner name is unsigned, which the
attacker cannot produce without the parent zone's signing key.
What remains is replay of a signed denial captured before the
operator deployed DANE, which leaves the client at SECURE_ABSENT or
INSECURE until the captured signatures expire. Section 13.2
describes that window and its bound. A deployment that wants to
close it can adopt the stricter policy of Section 6.4 of [RFC9289],
whatever the DNS outcome.
This is the same argument that supports opportunistic DANE for SMTP
[RFC7672]; on opportunistic security in general, see [RFC7435].
Appendix B. Open Issues
This section is to be removed before publishing as an RFC.
Each item is tracked as an issue in this document's issue tracker,
where the detail and the discussion live.
* Section 9.2: whether the partition of AUTH_TLS probe results, and
in particular which of them count as DECLINED, preserves
reachability to the pre-[RFC9289] server population. Issue 3
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/3)
Lever Expires 5 April 2027 [Page 36]
Internet-Draft RPC TLS with DANE October 2026
* Section 9.3: whether cleartext operation remains permitted where
no floor has been pinned and the server declines, or opportunistic
mode takes the stricter policy of Section 6.1.1 and Section 6.4 of
[RFC9289]; and whether a failed handshake is remembered across
association attempts. Issue 4 (https://github.com/chucklever/i-d-
rpc-tls-dane/issues/4)
* Section 8.1: whether support for certificate usages PKIX-TA(0) and
PKIX-EE(1) stays optional, or a client always treats records
carrying them as unusable. Issue 5
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/5)
* Section 9.5: how a resumed TLS session, in which the server
presents no certificate, satisfies the DANE authentication the
current attempt's DNS outcome requires. Issue 9
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/9)
* Section 9.1: whether a security floor covers connections to other
RPC programs on other ports of the same server, such as RPCBIND,
or only the port it was determined on. Issue 10
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/10)
* Section 6: how a reference name that is unqualified, or that does
not resolve in the DNS, is handled. Issue 11
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/11)
* Section 5.3: whether a floor is withheld on a port learned from an
unauthenticated source. Issue 12 (https://github.com/chucklever/
i-d-rpc-tls-dane/issues/12)
* Section 7.3: whether the client expands a CNAME alias to find the
TLSA base domain, or queries only at the reference name. Issue 13
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/13)
* Section 9.5: whether one evaluation of the DNS outcome is
authoritative for an association attempt. Issue 14
(https://github.com/chucklever/i-d-rpc-tls-dane/issues/14)
Acknowledgments
Much of the prose in this document was generated by Claude, a large
language model, working from the editor's design, outline, and
instructions, and was reviewed and revised by the editor, who is
responsible for its content. Claude is not an author of this
document.
The editor is grateful to Bill Baker, Greg Marsden, and Martin
Thomson for their input and support.
Lever Expires 5 April 2027 [Page 37]
Internet-Draft RPC TLS with DANE October 2026
Special thanks to Area Director Gorry Fairhurst, NFSv4 Working Group
Chair Brian Pawlowski, and NFSv4 Working Group Secretary Thomas
Haynes for their guidance and oversight.
Author's Address
Charles Lever (editor)
United States of America
Email: cel-ietf@chucklever.net
Lever Expires 5 April 2027 [Page 38]