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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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