]>

United States of America cel-ietf@chucklever.net

Web and Internet Transport Network File System Version 4 RPC TLS DANE TLSA DNSSEC STRIPTLS 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the nfsv4 Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction RPC-with-TLS protects Remote Procedure Call traffic by encapsulating it in a TLS 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. requires every RPC-with-TLS implementation to support authenticating server certificates by PKIX 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.

anticipated these problems and pointed at the same remedy for them, DNS-Based Authentication of Named Entities (DANE) , 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 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, 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 and and making the RPC-specific choices those documents leave to application protocols.

Scope This document defines client behavior and changes nothing in the protocol an RPC server implements. Its one requirement on the server side, in , binds the publisher of the TLSA RRset. Interoperation with a client implementing this document also depends on two matters of server configuration that 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. 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 . This document applies where the server authenticates itself with a certificate. A server association that uses the pre-shared key mechanism of 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 (). 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. also provides for matching a DANE-EE(3) record against a raw public key ; defines no way to convey one, so that case does not arise here. TLSA owner names are defined here for the transports 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.

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 that does not is unaffected. Two requirements of are changed here:

• 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 and restated in .
• Where cites for certificate name checks, clients implementing this document perform those checks per , which obsoletes . The additional restriction in , that a DNS domain name in an RPC-with-TLS certificate contain no wildcard character, is retained.

Elsewhere 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 recommends a TLSA check before an association is initiated, and disconnection when TLS or authentication then fails. , , and replace that recommendation.
• The second bullet of 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. and require the server-authentication half of that behavior where this document pins a security floor; the client-authentication half is out of scope (). Where no floor is pinned, permits cleartext operation on a well-formed decline; a deployment that adopts either recommendation in full remains conformant.
• leaves to local policy whether RPC operation continues in cleartext when the AUTH_TLS probe does not yield the "STARTTLS" indication. specifies that policy, and it is more restrictive than what permits.

This document also extends the audit log that requires: 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 , nor its provisions for pre-shared keys or for RPCSEC_GSS.

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 when, and only when, they appear in all capitals, as shown here. This document assumes a working knowledge of RPC version 2 , of RPC-with-TLS , and of DANE . It uses the DNSSEC validation states "secure", "insecure", and "bogus" as defined in . The definitions of "indeterminate" in and differ; this document classes a result that is indeterminate in either sense as ERROR (). 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 (), it is the name the upper-layer protocol supplied. 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 . A client may have more than one candidate base domain for a single reference name; see .

Selected TLSA base domain:

The candidate TLSA base domain at which the client found a validated TLSA RRset. See .

DNS outcome class:

One of the five results defined in 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 and as further constrained by .

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; 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. states the requirement.

DANE policy mode:

The client's configured disposition toward DANE for a given server association: disabled, opportunistic, or mandatory. See .

Overview of Operation A client that has DANE enabled for a server association performs, in addition to what already specifies, the following steps.

1. It derives a reference name for the server it is about to contact, subject to the requirements in . 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 .
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. specifies this procedure.
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 (), unless the port is of untrusted provenance (). 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 () where the client found a usable record, and by the PKIX rules of otherwise.
5. It records the policy inputs, the decision, and the authentication result in the audit log that already requires ().

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; states the constraints that any division has to respect.

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 .

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 withholds it, and constrains the association as specified in and . SECURE_ABSENT and INSECURE do not pin a floor; a floor pinned by an earlier attempt still governs the association, and otherwise governs whether the attempt may proceed in cleartext. Any TLS session established is authenticated by the PKIX rules of . ERROR fails the attempt (). This mode is intended for fleet-wide deployment against a server population that has not uniformly published TLSA records; see .

Mandatory:

The client performs the procedures in this document and 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 () 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.

TLSA Records for RPC Services

Owner names TLSA owner names for RPC services follow the convention in 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 and of ; 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".

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 observes that a successful AUTH_TLS probe on one port and transport implies nothing about any other.

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 , 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 () and pins no floor. Accordingly:

• DANE authentication as specified in applies at whatever port the client connects to, whatever the provenance of that port.
• A client MUST NOT pin a security floor () 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. describes how a client obtains ports from an authenticated source.

Publishing and key rollover Publishers MUST observe the requirements of , 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.

The Reference Name

Requirements on the reference name The TLSA base domains a client considers MUST be derived from the association's reference name, as specified in . 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 .
• An internationalized domain name MUST be converted to A-label form before it is used to construct an owner name, as requires.
• The value MUST satisfy the syntax and length limits for DNS names in , 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 .
• 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 or as a PKIX reference identifier.

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 . The same holds for a destination whose configured name fails the input contract above. For such a destination:

• In opportunistic mode, the attempt does not pin a floor. If an earlier attempt pinned one, that floor still governs the association; otherwise governs whether the attempt may proceed in cleartext. If the client authenticates the server, it does so by the rules of , which provide for matching an iPAddress subjectAltName.
• In mandatory mode, the association attempt fails ().

Locating the TLSA RRset

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 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. 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 that has fallen out of date is subject to the same rule.

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 .

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.

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 and of 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.

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

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

Evaluation and result reduction A client evaluates the candidate list in order, as shown in .

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.
• A validated denial of existence continues the search, per , 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.

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 .
3. Apply digest algorithm agility per : 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. 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.

The selected TLSA base domain, SNI, and reference identifiers The selected TLSA base domain is the candidate at which the evaluation in 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 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 . 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 then requires. This departs from 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 () in both cases, so that an operator can see which name the policy decision was derived from.

Authenticating the Server

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 and of respectively. recommends exactly this pair, and cautions that simultaneous support for all four usages is not recommended. 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 . Where such records are the only ones published, the outcome is SECURE_UNUSABLE, and requires the client to authenticate the server by the PKIX rules of . That check is weaker than the published records call for, but never weaker than 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 lets publishers rely on. Support for SHA2-512(2) is RECOMMENDED.

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 . When such a match succeeds, the server is authenticated. In particular, and following :

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

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 , and then performing name checks against the reference identifiers determined in . Those name checks are performed per , retaining the restriction in that a DNS domain name in an RPC-with-TLS certificate MUST NOT contain the wildcard character "*".

Required client behavior by outcome class 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 (). In every case where authentication is required, failure of that authentication fails the association attempt; see . The requirement that TLS be used is carried by the security floor. Where the DNS outcome was derived from a port of untrusted provenance, withholds that floor, and in opportunistic mode 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. Required client behavior by DNS outcome class

DNS outcome	Opportunistic mode
SECURE_USABLE	TLS is required, and the server MUST be authenticated by DANE per . PKIX authentication MUST NOT be substituted for it.
SECURE_UNUSABLE	TLS is required, and the server MUST be authenticated per .
SECURE_ABSENT	This outcome does not pin a floor. A floor pinned by an earlier attempt still governs the association; otherwise governs cleartext operation. A TLS session is authenticated per .
INSECURE	As for SECURE_ABSENT.
ERROR	The attempt MUST fail.

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 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 and , which require only unauthenticated TLS in this case; 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 the server presents an identity that the client can authenticate, and 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.

Downgrade Resistance

The security floor A DNS outcome class of SECURE_USABLE or SECURE_UNUSABLE pins a security floor for the server association, except where 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 (). 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 (). 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 , to which 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.

AUTH_TLS probe outcomes 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 .

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

Cleartext fallback 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 (). Cleartext fallback by AUTH_TLS probe outcome

Probe outcome	Floor pinned	No floor pinned
ACCEPTED	Proceed to the TLS handshake.	Proceed to the TLS handshake.
DECLINED	The attempt MUST fail.	Cleartext operation is permitted, subject to local policy, per .
Any other	The attempt MUST fail.	The attempt MUST fail.

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 , at the cost of reachability to servers that predate it, is open. https://github.com/chucklever/i-d-rpc-tls-dane/issues/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. 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.

Coherence within an association attempt How an implementation obtains DNS data, how many times within one association attempt it evaluates , 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 (), 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 () 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 , both RRsets match the certificate the server presents and the attempt succeeds whichever one the client uses.

Association Scope and Policy Granularity

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.

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 (). A client MUST refuse an addition that does not meet both conditions and record the refusal (); the association continues over the transports that do meet its floor.

Derived associations Upper-layer protocols direct clients to establish further associations to destinations the client did not select. NFSv4 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 ; an address literal gives the derived association no DANE binding (). 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 (), even though this may render some upper-layer features unusable (). 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.

Auditing A client implementing this document MUST extend the audit log that 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 ();
• the selected TLSA base domain, where one was determined;
• the AUTH_TLS probe outcome (), 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.

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.

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

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 (); the candidate determination and result reduction of , including secure CNAME expansion; the five outcome classes of ; the usability filtering and digest algorithm agility of ; the reference-identity rules of ; certificate usage DANE-EE(3) (); and the authentication behavior of 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 , which belongs to the RPC client rather than to the handshake agent.

Licensing:

GPLv2.

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 for the SECURE_UNUSABLE class was added after the implementation hit the handshake failure that section describes.

Security Considerations The security considerations of , , , and apply.

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 (). A deployment that relies on certificate contents for authorization -- an extended key usage check, a certificate policy, a subjectAltName URI -- as 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 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.

Replay and the limits of revocation DNSSEC provides no way to revoke a signed RRset before its signatures expire (). 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 (). 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 treats the zone as unsigned (); 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 disregards the certificate's validity dates, the RRset's signatures are the only expiry. The mitigation is operational and belongs to the publisher (). A security floor, once pinned, persists for the lifetime of the association (). 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 , so within the replay window an attacker who can present a certificate those rules accept regains the substitution that forbids for SECURE_USABLE. Where the client trusts no certification authority that would issue such a certificate, as in the deployment 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.

Fail-closed behavior is a denial-of-service surface The rules in , , and require a client to fail an association attempt in circumstances where an 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 (), so a disruption of DNS that coincides with the loss of a connection keeps the association from recovering. 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.

Unauthenticated port selection The rule in , that a floor is pinned only on a port of trusted provenance, keeps an attacker who substitutes the port in an RPCBIND 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 client. An RPCBIND reply carries a universal address (), 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 , 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.

Derived associations A security floor does not extend to an association whose destination an upper-layer protocol supplied (). The practical consequence for NFSv4 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 (), which makes the limitation visible rather than silent, at the cost of the feature.

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 discusses, and the precautions given there do not reach it. surveys what DNS transactions disclose. Two mitigations are available, and each is partial. An encrypted transport to the resolver () 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 (). Pervasive monitoring of DNS is a known concern for DANE generally.

Client authentication This document specifies the authentication of a server to a client only. 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 , 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. Until then, a deployment that requires mutual authentication uses the PKIX mechanism of for the client direction and DANE for the server direction; applies to the server's certificate whether or not the client presents one.

IANA Considerations This document requests no IANA actions.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in transit. The proposed mechanism interoperates with Open Network Computing (ONC) RPC implementations that do not support it. This document updates RFC 5531. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. Salesforce OpenSSL Corporation The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server.

Deployment Considerations

Publishing TLSA records for RPC services The simplest conforming deployment, and the one that addresses the operational problem described in , 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:

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 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 . Withdrawing DANE takes the same posture: a client that has pinned a floor for an association keeps requiring authenticated TLS until that association ends (), 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 , except that of a replayed proof of an unsigned delegation, which the parent zone's signatures bound. 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 (), 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; states the requirement. The Server Name Indication value such a deployment receives is not fixed. 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 RRset matches, when the SNI value is absent or unrecognized. gives SMTP servers the same guidance for the same reason.

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.

Downgrade resistance of opportunistic DANE Opportunistic mode () 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. describes that window and its bound. A deployment that wants to close it can adopt the stricter policy of , whatever the DNS outcome. This is the same argument that supports opportunistic DANE for SMTP ; on opportunistic security in general, see .

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.

• : whether the partition of AUTH_TLS probe results, and in particular which of them count as DECLINED, preserves reachability to the pre- server population. Issue 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 and Section of ; and whether a failed handshake is remembered across association attempts. Issue 4
• : 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
• : 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
• : 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
• : how a reference name that is unqualified, or that does not resolve in the DNS, is handled. Issue 11
• : whether a floor is withheld on a port learned from an unauthenticated source. Issue 12
• : whether the client expands a CNAME alias to find the TLSA base domain, or queries only at the reference name. Issue 13
• : whether one evaluation of the DNS outcome is authoritative for an association attempt. Issue 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. 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.