Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

David Noveck <davenoveck@gmail.com> Fri, 10 April 2020 12:40 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB933A08BD for <nfsv4@ietfa.amsl.com>; Fri, 10 Apr 2020 05:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p3rF0D82Tah for <nfsv4@ietfa.amsl.com>; Fri, 10 Apr 2020 05:40:43 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3F53A0776 for <nfsv4@ietf.org>; Fri, 10 Apr 2020 05:40:43 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id cb27so2245887edb.11 for <nfsv4@ietf.org>; Fri, 10 Apr 2020 05:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m94zUFf06mAbgZOAFjGdXunWh04kb8FNk6pc8GBldCg=; b=tYI7QioueS77lyDgXxxg9y6DRWfFcYZLpjRFKXG4+6OOGqTgTHJZESUNhkRBTfr3Jj njB/WfFP9/uTBBhKmz2x2ckT5bO3F0L8Uea1Ln+dQQhO0qeJdZJnLIEMefoaL+pMrFKF jktgkIp0c9rJV10JA+NzVF327RaN6G66s9N5ddF4ZOoSNPmvymPCKRL64BPORj3h4v46 CPkIOFrvaMt4iAwislJ0yexGnMbjR+UKNQ+4VVpZAitLiwjcxgeBJwixW0gwitJpxl9f MdQHdEa5HH5oHsVJb9lHs66ooBq+44wFMYjSTI05SlxJtlyeIAxMlqZf08N7i3Q25asE 5Peg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m94zUFf06mAbgZOAFjGdXunWh04kb8FNk6pc8GBldCg=; b=L5eo3/ssOWKIMHAgAIjFBgDzvdgdGTHkbyUUfu3qnmHUXF4v8c61CFls6WZABUW+6Y fMxpvtSfrIyA+Fk6IgUSYcJIS9ADIMfjYOnTS6DZXxy+ZJCSErYEHHza1mdWvwqNItpc SUJNlxZi9CEijBun6PYzwmLe6Ufs497P4eL6blkeQQTWgl9AZ19UHjpcMjzuA1mtafOf 9fwxGswdnH709ufks90Lffx9eCBBZvNivcn2pjheYPpaIWoQNN4Gic9kAstVGEIHjscG McTK2knVtQmPFn+O5/xJ4V5eRoH8O+rwmcNQwqs1QnciXYeQePgNwltcUeU+QGy79cjl o5Dw==
X-Gm-Message-State: AGi0PuajCdmfTJKbEbskMqZ2GPfQdz/NRJuT5JctswVd9xMBgf4rWddD bQ+vgmJwNmcAiKwGufuoCULThgVEPDAG4avP6os=
X-Google-Smtp-Source: APiQypLU4xE87CBpdQ2g+ycrZ0Kp6M1h+V72sLv3aG/SlMlg2CjPpFjjj4QqHp07+u8tZkc93KsCxvTp4vruwHaW2LI=
X-Received: by 2002:a17:906:493:: with SMTP id f19mr3536709eja.171.1586522441418; Fri, 10 Apr 2020 05:40:41 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com>
In-Reply-To: <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 10 Apr 2020 08:40:28 -0400
Message-ID: <CADaq8jcVe=g2Sao_X+tsQowm=Lus3dv=wbqiK4gc3k6ejdXEOA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c8d5f05a2ef0a86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/3VM8GFrJrjtd2_uKfA_Yi7M22Nc>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 12:40:45 -0000

On Thu, Apr 9, 2020, 3:28 PM Chuck Lever <chuck.lever@oracle.com> wrote:

>
> > On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
> >
> > 8. Section 5.1.2:
> >
> >    As soon as a client
> >    initializes a socket for use with an unfamiliar server, it uses the
> >    mechanism described in Section 4.1 to discover DTLS support and then
> >    negotiate a DTLS session.
> >
> > So first of all is the usage of TLS for TCP completely separate from
> using DTLS over UDP?


It seems that that was Chuck's intention and was the way I have been
reading the spec.  However, it is not explicitly stated right now and does
need to be clarified as part of the response to Magnus's review.


> So having determined TLS support for TCP does not indicate the same for
> UDP?


I would hope not.   Ad a practical matter, there are many servers that
would not be all
interested in implementing DTLS, given that UDP is not allowed by NFSv4.
 Tying this
to TLS support would haveth effect of increasing the effort to provide
support without
correspondingly increasing the benefit.

Even though we cleary don't have consensus on the TCP-connection-sharing,
we might
well have consensus on this.

And is it in any cases possible to skip the initial RPC null request with
> AUTH_TLS authentication and go directly to negotiate TLS after support has
> been determined with a server?
>
> rpc-tls does not discuss this a possibility.  On the other hand it does
not forbid it either.
Addressing this whole area is part of the needed clarification.

rpc-tls is written assuming opportunistic TLS access is the only means
of RPC-TLS  access but it never states that explicitly.  As a result,
Magnus,
quite reasonably, asks whether there are cases in which opportnistic acces
might be used as an information-gathering mechasnism to support non-
opportunistic TLS access.


> There seems to be a high-order bit here that rpc-tls does not currently
> address. Leaving it unaddressed could introduce significant
> interoperability issues.
>
> I don't think that's the high order bit but I agree it does need to be
resolved :-(


> Our new STARTTLS RPC NULL probe carries an RPC program.


It does.


> Does a successful
> probe mean that the RPC server supports TLS for every RPC program on that
> that host? on that port? Or just for the program used in the probe? I think
> it means TLS can be used only with the RPC program used in that probe,


While I read things that way, I'm not committed to that reading.   Given
the lack
of consensus on that point, I want to understand how important that
reading is to you.


> and only for the lifetime of that connection. (ie each connection has to
> do the probe).
>
> I think that part is the high-order bit.   I'm hoping we might be able to
get
consensus on that since I feel that changing that might be more disruptive
than restrictions on the program used which run into the contentious
connection-sharing issue.


> Since the STARTTLS RPC NULL probe is always done in clear-text, that means
> a second probe cannot be done once a TLS session has been established on
> a connection.


Right.


> (A separate connection must be established to initiate a
> second TLS session).
>

That's not made clear in rpc-rls but I hope that everyone is OK with that
being made explicit.


>
> Therefore with RPC-on-TLS we do not allow multiple RPC programs to share
> a TLS session.


 What is the justification for the "therefore"?

Although we may reasonably conclude that a successful STARTTLS indicates
that you do may support for the specified program and version, I don't see
that
you are forced to conclude that no other program is supported.   I read it
that
way because the connection sharing case isn't important to me, but, since
it appears
that we can't reach consensus on that, we might want to consider
whether being
more relaxed on that point is a viable path forward.

And we do not allow multiple RPC-on-TLS sessions per TCP
> connection.
>
> Yes.


> For DTLS, the STARTTLS probe has to be done for each RPC program on each
> server. Only that one RPC program can use the established DTLS session.
>
> I hope we can achieve consensus on that.

>
> This means RPC-on-TLS robs us of some TCP connection sharing opportunities.
>

I don't feel robbed, but it appears some people do :-(


> Is there consensus on this,


I appears not.


> or should these design points be revisited?
>
> Not all of them,   I would hope we can disturb as few decisions already
made as possible.


> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>