Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

David Noveck <davenoveck@gmail.com> Thu, 24 October 2019 16:42 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9680312096D; Thu, 24 Oct 2019 09:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 axFIkM6Z6g75; Thu, 24 Oct 2019 09:42:28 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 44B7612097D; Thu, 24 Oct 2019 09:42:15 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id u13so2485770ote.0; Thu, 24 Oct 2019 09:42:15 -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=RJYuInH9kyDZC5vPh0bWoSZUIWtn+n+xFNp4vSPwhm0=; b=Dqhf20EgSXVVg/wsJipoZ+Ie5mKNXLgyVDtK9cGsKzm6AXMR116Yfmn82GfES5QHLC SONHuuzao84d0KaFx/GbAU9nmoN9urC4KseCXadG/G5l/tfrBGwhwlZJaXfug4PH1yWH 1hY7/8ihREdKM5kTv6ed1M3lcwdgao9870Yj85ZL6SFS8ROMGGmzGZnqjpKnnozfp9YZ wQc5/BP8e3cypTynQdHY1vbOXtg2EIe/Jbuzgsltn4nLJaBGmSXdbNICRk/vGcJKTLrf 9jHIecYSSOrzi4GcTgiMN12HrzPSLggWeVT2jWeC8IIny7hlArRVLJqixJPOdfwdEsuS MY9Q==
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=RJYuInH9kyDZC5vPh0bWoSZUIWtn+n+xFNp4vSPwhm0=; b=LwzLg9bJN6ljNxJI3tC1C+Pd+7brNPlrX2S5GfT5kh2yWc753gX58/+IrWyJ0GSaBh SnAGoa2d/kP57FVsjy2f1j16d+l072Qu4APLD+tNEm4vzRWaFOwhTZcF7WKF5t60KyQt bPsbhnBW05yk0quiTAMLhWnWQc1qD041n4xVsclFILJVJPVP2Akj8uhkYP3ld43cJamn Usi/wJw5QLmHwm9lVviFbgwNw8BxKnatg9dyfshseCneh/ZphIom8bAM1up6/aZBIWkt If7TpvhiLk9Y/rnVTnuC4wU3GY2J1zyDDK5+S5gcs7C2JkDzGu8dZZuGS+ybQn0YKKac iX7A==
X-Gm-Message-State: APjAAAXNkEqPFIkwIj5ocqj0eDYl4Ijg9uUH4opfRRBrepOtHSnNAOwl fUcB+7gbZ2FjsYxQJQgYCdgiLG3TvjHcRLV7a2U=
X-Google-Smtp-Source: APXvYqwSiwjKnWmYvA8ea2gcUTs9uASE9NgJJgfLupvRto+yg2M+iqKoD4uR2ku6cP2oHMQwa4SMeXlWnMMpITiK04g=
X-Received: by 2002:a9d:721c:: with SMTP id u28mr12637543otj.359.1571935334416; Thu, 24 Oct 2019 09:42:14 -0700 (PDT)
MIME-Version: 1.0
References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> <CADaq8jfPjuMAm1r4zTG_30Qt7K8+Tp-qKPC01TGpK2-PRfDO0g@mail.gmail.com> <YTBPR01MB2845C63770AE520BA7CB8244DD6B0@YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM> <096259B5-3892-409E-8FE9-1920BA7175BD@oracle.com>
In-Reply-To: <096259B5-3892-409E-8FE9-1920BA7175BD@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 24 Oct 2019 12:42:03 -0400
Message-ID: <CADaq8jfpPQx188ZkBJ=DYSCMZg-J80K6KXjvgK=pc2qFnExVyQ@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Rick Macklem <rmacklem@uoguelph.ca>, Derrell Piper <ddp@electric-loft.org>, NFSv4 <nfsv4@ietf.org>, "draft-ietf-nfsv4-rpc-tls.all@ietf.org" <draft-ietf-nfsv4-rpc-tls.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037c4fa0595aab739"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/IZITGhEsrsBgGGA0lnQo0nXdVw0>
Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 16:42:31 -0000

> Indeed, they are permitted.

Otherwise there would be no point in writing this document.

> All legacy servers will take this form,

What form?

> and of course,

????

> if no certificate material is provided to a TLS-capable
> NFS server, it will act as if RPC-on-TLS is recognized but not
> supported.

i don't think this right.   I think encryption without authentication
is of real value if you have other ways of authenticating.   I think
it would be reasonable for server to be configured so as not to
accept use of auth_SYs fro unauthenticated clients.

> "Encouraged" is a bit strong, however.

It's weaker than "recommended", "required", "RECOMMENDED",
and "REQUIRED".   If you don't like those, you are gpoing to have
to say something beyond "OPTIONAL".   Even if there is no
RFC21119, you could describe 9normatively) describe use of this
as "valuable", "highly desirable".

> I think if we /encourage/ a
> behavior, it would be to encourage the use of RPC-on-TLS where it is
> practical.

We certainly don't want to encorage use of this where it is impractical.
If we did, nobody would listen to us, anyway.

Perhaps we can address this non-normatively by accurately describing
the consequences of not using this.   The document on NFSv4 security
will probably take that approach.

On Thu, Oct 24, 2019 at 9:14 AM Chuck Lever <chuck.lever@oracle.com>; wrote:

>
> > On Oct 23, 2019, at 5:13 PM, Rick Macklem <rmacklem@uoguelph.ca>; wrote:
> >
> > I'll admit I haven't read the most recent draft and haven't looked at it
> > in detail. However, my impression is that the reviewer might be more
> > comfortable if the draft makes it clear that "rpc-tls only" servers will
> > not only be permitted, but encouraged.
>
> Indeed, they are permitted. All legacy servers will take this form,
> and of course, if no certificate material is provided to a TLS-capable
> NFS server, it will act as if RPC-on-TLS is recognized but not
> supported.
>
> "Encouraged" is a bit strong, however. I think if we /encourage/ a
> behavior, it would be to encourage the use of RPC-on-TLS where it is
> practical.
>
>
> > (I don't see a "http" vs "https" distinction, but extant NFSv4 servers
> that
> > I am familiar with can be configured to only allow clients that use
> > RPCSEC_GSS and I would expect that rpc-tls enabled servers could be
> > configured the same way.)
> >
> > As an aside, I do plan on implementing this in Winter 2020, rick
>
> Thanks Rick!
>
> --
> Chuck Lever
>
>
>
>