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

Chuck Lever <chuck.lever@oracle.com> Tue, 01 September 2020 15:26 UTC

Return-Path: <chuck.lever@oracle.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 744AB3A0B8F; Tue, 1 Sep 2020 08:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=oracle.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 1sQN8qprsV17; Tue, 1 Sep 2020 08:26:25 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207463A0B8D; Tue, 1 Sep 2020 08:26:25 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 081FKwTM034967; Tue, 1 Sep 2020 15:26:24 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=2tHClOXA4owqEjA8NJy0giJAQyojjczcvfyfWXl7ues=; b=WbRYAGT1GpPBrfoyLw/QC5qFgB7fmcp97XKrIXP2vUtYD8wut++JExOTH3Kqf8eZ4vOF 96R2Ri5v3Bq1ozYjzsKLmxzENz1Stmb2OPk1oxknn7PoPmNUVE6kst8vigkFEp1lW0+3 +d26I2AuViDanv0Byjh9V5eEwmh0tpcoBWoP2mdY3ydeHflBs+9FS9Da7WHIN+r0m64P 3d+prdOvTAU2OPyPWD1JH7JzYHUdDOBA7/jUGOowgoXj8SNbSH3rKUMSHZfCwIS7+THV oB1Ni8VvbUTFJYtrRtWZiaOdF3zv4zKZysefqmdTFXwcQ7ZhiP/A8AqZfT6IZO1tx82H Ag==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 337eeqw245-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 01 Sep 2020 15:26:24 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 081FL0JC020173; Tue, 1 Sep 2020 15:26:24 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 3380srxr9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Sep 2020 15:26:24 +0000
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 081FQNIZ000386; Tue, 1 Sep 2020 15:26:23 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Sep 2020 08:26:22 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
Date: Tue, 1 Sep 2020 11:26:21 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <10A7F6F5-3EF6-481A-AFD7-4C30A2F59E88@oracle.com>
References: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9731 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 phishscore=0 malwarescore=0 mlxscore=0 spamscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010126
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9731 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010126
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Sxprneg43zRO1k-7q2dkFKwNuEA>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
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: Tue, 01 Sep 2020 15:26:26 -0000


> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <noreply@ietf.org> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (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.


--
Chuck Lever