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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Oct 2020 14:35:56 -0700

Hi Chuck,

Thanks for these, and thanks for all the updates in the -09.
AFAICT the -09 does address all of my discuss points on the -08, though
unfortunately it did introduce one more issue.  (The short form: RPKI is a
completely different PKI than the Internet PKI, and RPC server certificates
are not Resource Certificates.  More on that under separate cover.)  I'll
be going through this thread in reverse chronological order to reply to
anything still outstanding, and will then update my ballot position to
be an accurate reflection of the state of the -09, even if some of it is
already covered in email by that point.

Sorry to have taken so long to get back to you -- I was not entirely
healthy when this came in and wanted to wait until I had my full wits about
me to be sure I was saying correct and sensical things.

More inline.

On Fri, Sep 11, 2020 at 12:48:32PM -0400, Chuck Lever wrote:
> Hi Ben-
> 
> I'm nearly done with the new text. I need some clarification below.
> 
> 
> > On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-nfsv4-rpc-tls-08: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > I'm surprised that we don't make a normative reference to BCP 195's
> > "Recommendations for Secure Use of Transport Layer Security (TLS) and
> > Datagram Transport Layer Security (DTLS)" (we have only an informative
> > reference from the security considerations).
> 
> Is there a specific change you'd like to see?

I think we could probably add another bullet point in Section 5 (probably
as the second point), along the lines of:

* Implementations MUST conform to the recommendations for TLS usage
  specified in BCP 195 [RFC7525].  Note that although RFC 7525 permits use
  of TLS v1.2, the requirement to use TLS v1.3 or later for RPC-over-TLS
  takes precedence.  Since TLS 1.3 ciphers are qualitatively different than
  cipher suites in previous versions of TLS and RFC 7525 predates TLS 1.3
  [RFC8446], the cipher suite recommendations in [RFC7525] do not apply.  A
  Strict TLS mode for RPC-over-TLS and protections against TLS Stripping are
  discussed in <appropriate section reference; 7.1.1?>.

And, gosh, writing all those caveats makes me realize that I should be
pestering the TLS WG more often about updating BCP 195 for TLS 1.3!

> 
> >   *  Host identity management and user identity management must be
> >      enforced in the same security realm.  In certain environments,
> >      different authorities might be responsible for provisioning client
> >      systems versus provisioning new users.
> > 
> > I think this is only true from a certain point of view.  They have to be
> > related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
> > thing) a cross-realm relationship would have to exist in at least one
> > direction when client system and user provisioning are managed by separate
> > kerberos realms, but the authorities in question do not need to be exactly
> > the same.
> 
> I'm not clear what needs to change.

Sorry for being obtuse; I was just looking for something like s/must be
enforced/are quite complex when they are not/.  In that it's technically
possible, but (AFAIK) nobody does it.

> >   Encryption By Default:  Transport encryption can be enabled without
> >      additional administrative tasks such as identifying client systems
> >      to a trust authority, generating additional keying material, or
> >      provisioning a secure network tunnel.
> > 
> > To clarify Roman's comment, it seems worth specifying that this is without
> > additional *per-client* keying material.  Generating per-server keying
> > material is clearly a minimum requirement.
> 
> The text was updated at Roman's request. It now reads:
> 
>    Encryption By Default:  Transport encryption can be enabled without
>       additional administrative tasks such as identifying client systems
>       to a trust authority and providing each with keying material.
> 
> Can you confirm this adequately addresses your comment?

Yes, that's all good.

> > Section 4.1
> > 
> >   The mechanism described in the current document interoperates fully
> >   with RPC implementations that do not support RPC-over-TLS.  Policy
> >   settings on the RPC-over-TLS-enabled peer determine whether RPC
> > 
> > I'd consider joining the two sentences via ", subject to policy settings on
> > the RPC-over-TLS-enabled peer that determine".
> 
> The text was updated at some point during IESG review. It now reads:
> 
>    The mechanism described in the current document interoperates fully
>    with RPC implementations that do not support RPC-over-TLS.  When an
>    RPC-over-TLS-enabled peer encounters a peer that does not support
>    RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer
>    determine whether RPC operation continues without the use of TLS, or
>    RPC operation is not permitted.
> 
> Can you confirm this is adequate?

Yes, thanks.

> >   As soon as a client initializes a UDP socket for use with an RPC
> >   server, it uses the mechanism described in Section 4.1 to discover
> >   DTLS support for an RPC program on a particular port.  It then
> >   negotiates a DTLS session.
> > 
> > We could probably normalize the wording between the TCP and UDP cases (e.g.,
> > TCP says "typically, once a client completes the TCP handshake, it uses the
> > mechanism [...]" but this uses descriptive text).  That would also let us
> > decide whether or not to mention that (D)TLS usage is contingent on mutual
> > support for STARTTLS.
> 
> The reason the TCP and UDP text diverge is because TCP is connection
> oriented and UDP is not. The current UDP text is the result of some
> earlier review comments in this area. Let me know if there is a
> specific change you'd like to see here.
> 
> Also, I don't understand the last sentence of your comment. Can you
> elucidate?

Basically, I was looking at the quoted paragraph above and comparing it to
... hmm, now it no longer seems obvious what I was comparing it to; no
wonder you were having trouble!  It must have been:

[ The use of the Transport Layer Security (TLS) protocol [RFC8446]
[ protects RPC on TCP connections.  Typically, once an RPC client
[ completes the TCP handshake, it uses the mechanism described in
[ Section 4.1 to discover RPC-over-TLS support for that connection.
[ Until an AUTH_TLS probe is done on a connection, the RPC server
[ treats all traffic as RPC messages.  If spurious traffic appears on a
[ TCP connection between the initial clear-text AUTH_TLS probe and the
[ TLS session handshake, receivers MUST discard that data without
[ response and then SHOULD drop the connection.

Something analogous for DTLS could be

% The use of the Datagram Transport Layer Security (DTLS) protocol
% [RFC6347] protects RPC carried in UDP datagrams.  Typically, as soon as a
% client initializes a UDP socket for use with an RPC server, it uses the
% mechanism described in Section 4.1 to discover RPC-over-DTLS support for
% that association.  Until an AUTH_TLS probe is done on that socket, the
% RPC server treats all traffic as RPC messages.  If spurious traffic
% appears on a 5-tuple between the initial clear-text AUTH_TLS probe and
% the DTLS association handshake, receivers MUST Discard that data without
% response.

(The lack of "SHOULD drop the connection" at the end is intentional.)

I think my last sentence was complaining about the phrasing of "discover
DTLS support for an RPC program", though looking at it again it does not
seem particularly objectionable.

In any case, the whole point of this comment was a stylistic matter, noting
that there could be parallelism of text structure between the TCP and UDP
cases, if desired.  There is no requirement for such parallelism, and I
apologize for having spent so many words on the topic.

> > Section 8.1
> > 
> > Isn't it codepoint squatting to claim auth flavor 7 before IANA has
> > allocated it?  (This is usually a Discuss-level issue, but that part is too
> > long already so I left it here.)
> 
> I agree it is slightly improper, but the authors were not aware of
> IANA's authority over RPC authentication flavors until late in the
> document's life cycle. It was a good faith oversight.
> 
> I believe we have IANA's permission at this point to use the value 7.
> 
> Is there a text change needed here?

(I read the follow-ups as well.)
Typically we would say "7 (to be confirmed by IANA)" but just this point
alone does not merit a new I-D.  Since there will be a new I-D anyway,
though, might as well make this change, too.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Oct 2020 14:41:17 -0700

Hi Chuck,

I don't have any further comments on the below, and as I stated in an
earlier message the -09 addresses the discuss points.

I did, however, want to separately thank you for the thoughful analysis
(in this note) and rewrite of section 5.2.1; they are quite well done.

-Ben

On Wed, Sep 09, 2020 at 10:58:16AM -0400, Chuck Lever wrote:
> Hi Ben-
> 
> It appears that many of your comments have overlapping impact on
> the document, so I'm attempting to address all of them in my
> working copy of the document and will post proposals for replacement
> text once I feel that they coherently address your concerns.
> 
> More below.
> 
> 
> > DISCUSS:
> ...
> > (5) Section 5.2.1 requires that:
> > 
> >   *  Implementations SHOULD indicate their trusted Certification
> >      Authorities (CAs).
> > 
> > Indicate to whom?
> > 
> > (6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
> > intent.  Specifically, we seem to be saying "the peer gave me a cert, let me
> > look through it to see if it has something I like", but RFC 6125's intended
> > procedure is "I know a list of names that I expect to see at least one of in
> > the cert; these rules tell me whether the cert is valid for any such name".
> > It's not entirely clear that it's appropriate for this document to specify
> > how the client has to order its list of names by type (per Section 6.1 of
> > RFC 6125's "The client constructs a list of acceptable reference
> > identifiers"), which the bit about "The following precedence applies" seems
> > to be doing.  To the extent that we give a recommendation to use DNS-ID
> > instead of CN-ID, and ipAddress SAN instead of CN-ID, that's already covered
> > by RFC 6125; it would be okay for us to say "use DNS-ID or iPAddress SAN",
> > though.  (Roman's comment about "why not a normative MUST" for putting IP
> > addresses in the iPAddress SAN is related, and if we don't have a compelling
> > reason to allow the flexibility, we should limit to the specific
> > DNS-ID/iPAddress options without allowing CN-ID.)
> > 
> > (6.1) Note additionally that if wildcard certificates are to be used, RFC
> > 6125 requires the application protocol specification to give details on how
> > they are to be used.
> > 
> > (6.2) RFC 6125's procedures are (facially, at least) only valid for TLS
> > server authentication.  We also want to authenticate TLS clients, so we
> > should say whether we expect the same procedures to be used, or what
> > procedures should be used (even just as how it differs from the RFC 6125
> > ones).  Of particular note is that, since the server is not initiating the
> > network connection, it is unlikely to have a preconceived notion of what
> > client identity to expect, and is likely limited to attempting to extract
> > something from the certificate.  In this scenario a precedence list (as I
> > complained about being inconsistent with RFC 6125 above) would be
> > appropriate.
> 
> These two DISCUSS points are related to Section 5.2.1, and will
> likely have to be dealt with by rewriting that section. The crux
> of your commentary seems to be:
> 
> --- Clients use different logic for authenticating and authorizing
> a TLS session than servers do, and what rpc-tls provides is a jumble.
> 
> As you point out, RFC 6125 stipulates that clients authenticate a
> server by checking its presented identity against a list of known
> identities. I don't see a need for rpc-tls to further decorate the
> process laid out in RFC 6125, and I don't know of any issue with
> disallowing CN-ID.
> 
> rpc-tls still thinks about the server-side authorization process in
> terms of the NFS server's legacy IP access control list. Instead we
> should think of it like GSS: the RPC layer handles authorization, full
> stop, and nothing need be exposed otherwise. The peer's IP address may
> be exposed to the upper layer service, but I don't see that rpc-tls
> needs to take a position on that; it's an implementation quality issue.
> 
> However, rpc-tls does need to provide explicit instructions for servers
> to authenticate clients. Thus editorially I think we need to split
> Section 5.2.1 into a section that describes server authentication of
> clients, and client authentication of servers.
> 
> I'm wondering if the PSK section likewise needs bifurcation. But also,
> I'm not sure that the PSK identity needs to be surfaced, for similar
> reasons: TLS should handle authorization -- either the session was
> established by the rules, or it wasn't authorized, and that's all the
> upper layer consumer needs to be aware of.
> 
> Finally, there's the issue of whether a TLS exporter will be necessary
> for properly dealing with GSS channel binding. I haven't looked at that
> closely yet, but it might need to be partially addressed in 5.2.1.
> 
> I'm interested in my co-author's thoughts, as well as the opinions of
> those who have already implemented a RPC-over-TLS prototype.
> 
> 
> --
> Chuck Lever
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Oct 2020 14:49:53 -0700

On Tue, Sep 01, 2020 at 11:26:21AM -0400, Chuck Lever wrote:
> > (8) Can we clarify the status of DNSSEC (or DANE) requirements?  Section 1
> > assumes that support for DNSSEC is already available in an RPC
> > implementation, but Section 7.1.1 says that "Clients [sic] implementors can
> > choose from" a list of things including DANE TLSA records.  Why would we
> > require DNSSEC support but not using the records if they're present?
> 
> OK, I'm parsing this comment more closely now.
> 
> The statement in Section 1 you refer to above is:
> 
>    The protocol specification in the current document assumes that
>    support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available
>    in an RPC implementation where TLS support is to be added.
> 
> I hadn't counted this as a "requirement" since a BCP14 keyword is
> not used, and because it appears in the Introduction as background
> material.
> 
> Section 7.1.1 currently says this:
>                                                               Clients
>    implementers can choose from the following to mitigate STRIPTLS
>    attacks:
> 
>    *  A TLSA record [RFC6698] can alert clients that TLS is expected to
>       work, and provide a binding of hostname to X.509 identity.  If TLS
>       cannot be negotiated or authentication fails, the client
>       disconnects and reports the problem.
> 
>    *  Client security policy can require that a TLS session is
>       established on every connection.  If an attacker spoofs the
>       handshake, the client disconnects and reports the problem.  If
>       TLSA records are not available, this approach is strongly
>       encouraged.
> 
> Here, it is assumed that the RPC-over-TLS implementation has DNSSEC
> support. What is not assumed is that the peer always operates in
> an environment where the DNS administrator has configured TLSA
> records.
> 
> I'm open to suggestions on how to structure this section more clearly.

My main point (or question?) here is whether (or when) we require
RPC-over-TLS clients to perform TLSA queries when attempting STARTTLS.  The
current text in 7.1.1 comes across (at least to me) as a statement of fact:
if you want to protect against downgrade, TLSA records do that (when they
exist).  There is no requirement or suggestion to actually check for the
TLSA record and obtain that protection.  Now, making additional DNS queries
is not always great for performance, and if the client is running in an
opportunistic mode it may not care about the lack of downgrade protection,
so it's not a foregone conclusion that we should be putting in text like
"clients MUST check for the existence of a TLSA record for the target
server before initiating an RPC-over-TLS connection", but I do think we
should consider the question of what (if any) level of requirement is
appropriate and under what conditions.  (The flip side of this question is
that if we don't have any case where we require the use of the DNSSEC
support, we may not need to state that we assume it to be present.)

Thanks,

Ben

---

From: David Noveck <[email-masked]>
Date: Sun, 11 Oct 2020 08:37:57 -0400

On Thu, Oct 8, 2020, 5:50 PM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> My main point (or question?) here is whether (or when)

I think we may have to add (or where).

we require
> TLSA record and obtain that protection.

Yes.

Now, making additional DNS queries
> opportunistic mode it may not care about the lack of downgrade protection,

As I understand it, whether one is running in opportunistic mode is
currently left as a matter for "local policy". I think it is implied that
that policy could be constrained in ULP-specific documents.

> server before initiating an RPC-over-TLS connection",

I agree.

but I do think we
> appropriate and under what conditions.

The alternative is to leave this matter to the ULP's.

(The flip side of this question is
> support, we may not need to state that we assume it to be present.)

But the document that did add that use case would have to do so.