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

Chuck Lever <chuck.lever@oracle.com> Mon, 31 August 2020 15:06 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 B90F63A14B2; Mon, 31 Aug 2020 08:06:57 -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 5hTnlFR9EJki; Mon, 31 Aug 2020 08:06:56 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 093F73A0905; Mon, 31 Aug 2020 08:06:55 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07VF5Xx1130430; Mon, 31 Aug 2020 15:06:54 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=cwF/GXqKh9XgC5PBHqj8guVaxFNKOR7OxMNaThSQN2E=; b=MS/I9sV2IVV1lQ+RUr5at+x5SHJlJX1lIzKdtaqaT7/zBCZ/rgOymmh+wKMugcyUfcb5 npiAlM4VMH0WPNUXJHWWGsCxLdnpzzv9q2a3ukrB+5cE6wrKwWYmjIJN7L4NuTM3UhfL xtMNBL6UPdc9oR/yH6MB22XXzlHcquKMUY5zshFjaaQLllETUUlPR9YshcdUlEaToUXB KYzSOJUOKSsT820iEpq0DngEO3DGBewoezYwWr9xUZq76WgK0s7gxxTNrR5qhxE+Z0rv hliGawkO+LFKkFIuE5g6YwNvJTyJFfMGxkABpsvhP8dkqp2UThAWy5MYF9vg9xTrB6oR eg==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 337qrhdubb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 31 Aug 2020 15:06:54 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07VF5b9l068143; Mon, 31 Aug 2020 15:06:54 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 3380xuvm4x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 31 Aug 2020 15:06:54 +0000
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 07VF6q87004183; Mon, 31 Aug 2020 15:06:53 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 Aug 2020 08:06:52 -0700
Content-Type: text/plain; charset=utf-8
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: Mon, 31 Aug 2020 11:06:51 -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: <FBB12872-16B8-427B-89F3-FCE363B4E2F7@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=9730 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310090
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9730 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 spamscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310090
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/JZzZot545UvRPJuZjeeKvYIIOos>
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: Mon, 31 Aug 2020 15:06:58 -0000

Hi-

I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
current Editor's Copy with these changes can be found here:

https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html

In this e-mail I will try to address some of the simpler-to-manage
DISCUSS comments from your position. I plan to address the more complex
issues in subsequent e-mails.

I will also follow up with questions and proposals for addressing
COMMENT points in subsequent e-mails.


> 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:
> ----------------------------------------------------------------------
> 
> I support Roman's Discuss points.

I believe I've now addressed his DISCUSS points to his satisfaction,
and welcome your review of the new version of the document at the
link above.


> (1) I don't think that the claim in Section 4.2 that "[b]oth RPC and TLS have
> peer and user authentication" is correct, at least given my understanding of
> those terms.  Using this document's definition of RPC "peer authentication"
> as analogous to TLS server authentication, the functionality that TLS calls
> "mutual authentication" is more analogous to RPC client authentication,
> though it is sometimes repurposed for use for user authentication, with
> concommittant bad user experience.  This analogy does not seem critical to
> the mechanisms of this document, so I believe we should remove or modify it.

Perhaps it's a matter of terminology. RPCSEC_GSS "peer" authentication
is truly mutual. For AUTH_SYS, both peers identify themselves by a name
string in the RPC headers, though this is not cryptographically strong
and thus is typically ignored by receivers.

I'm open to specific suggestions about how to modify the text.


> (2) The mention of using RPCSEC_GSS with GSS channel bindings to TLS is
> quite underspecified. Unfortunately, this is largely the fault of other
> specifications, but we have to deal with the fallout.  On first glance (but
> subject to further clarification/change), it seems like we should:


I'm deferring a response to (2) until I've reviewed the kitten documents
you've mentioned. IMO introducing specific instructions for handling GSS
channel binding is appropriate, and I intend to propose text in a
subsequent e-mail.


> (3) Please check this reference in Section 5.1.1:
> 
>   Reverse-direction operation occurs only on connected transports such
>   as TCP (see Section 2 of [RFC8166]).  [...]
> 
> It seems likely that RFC 8167 was intended...

I agree. I'll fix this.


> (4) I don't think it's particularly safe to suggest that non-protected RPCs
> should be exchanged on the same 5-tuple that just terminated a DTLS
> association, since neither DTLS nor UDP provide in-order delivery, so there
> is ambiguity as to whether a datagram should be interpreted as DTLS
> protected or not.  This is particularly problematic in the face of the three
> different DTLS record headers (DTLSPlaintext, DTLSCiphertext(full), and
> DTLSCiphertext(minimal)) with something like 10 or 11 different possible
> values for the first byte that might be in flight, with limited "magic
> number" verification fields available.  I think I need some input from the
> TSV ADs about what the options are, though -- while a cooling-off period
> might be fine if an ephemeral port is in use, it seems problematic for cases
> where fixed port numbers are used for both source and destination.

This is a more complex issue, but I'm replying here to inquire if
you've yet been able to circle back with the TSV ADs. Additional
input is welcome.


> (5) Section 5.2.1 requires that:
> 
>   *  Implementations SHOULD indicate their trusted Certification
>      Authorities (CAs).
> 
> Indicate to whom?

The text is vague, but I assume based on context that the RPC-over-TLS
implementation indicates the list of trusted CAs to the RPC server to
make final decisions about authorization.


> (6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
> intent.

I'm deferring a response to (6) until I've reviewed RFC 6125 again.


> (7) Section 5.2.1 uses the phrase "renegotiate the TLS session".
> Renegotiation is not defined or allowed for TLS 1.3; generally one would
> need to either remember the presented certificate and re-run the validation
> process on it or shutdown the TLS connection and make a new one, though in
> theory one could try to define a mechanism using post-handshake
> authentication.  (I don't recommend the latter, though; it's not widely
> implemented/used.)

OLD:

implementations MAY renegotiate the TLS session to reassess the
connecting peer’s continued authorization.

NEW:

implementations MUST terminate the TLS session.


> (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?


I'm deferring a response to (8) until I've reviewed specifications of
other consumers of DNSSEC/DANE.


> (9) I agree with Roman('s comment) that Sections 5.2.2 and 5.2.4 should give
> a minimum amount of information to be exposed to the administrator for
> implementing the trust mode.

Section 5.2.2 (Certificate Fingerprints) has been removed because of a
variety of unresolvable issues.

Section 5.2.4 (Token Binding) has been removed because there is currently
no active Internet-Draft or plan to support token binding in TLS 1.3.

We are leaving these areas open for future standards work.


--
Chuck Lever