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

Chuck Lever <chuck.lever@oracle.com> Tue, 14 July 2020 11:52 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 878973A0AFA; Tue, 14 Jul 2020 04:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, 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 YEyYBh4G1Utz; Tue, 14 Jul 2020 04:52:56 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 7C72D3A0AF8; Tue, 14 Jul 2020 04:52:56 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06EBkvgQ007435; Tue, 14 Jul 2020 11:52:53 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2020-01-29; bh=B6TC9hUfkr9t7Xf33c1sId46+ZKNK2qxTRZ16HGYCho=; b=Vh/1K3kM/GANlmV9guRSrjQ7Kl7wFF0bgLbWybZAnlUV6+8G/YHgNOxvxiIy1b6WZuje rxdrIq8iFtGZfZAn09A4giLTjKKlrohTskeGnbMoZWECf37agL/SRZuX7P8OJKmzm9Bs ZjBws6ZAW4n6BFHDEzVlco1+lZAsfcCL9fNrZPqdTIdeiON1tqZIHOs/xi35+GATQ9x+ ch713S/ymUy/W2i3tKSYV/MhPgTIXw0a7MDV+p7bMPsw+kpRSxrsFKvoO07avAF/9n5p JjE54o5dRXF/UvC1kCbc6R0t3F8zLWmdazfiQrzlG3enNvGYhokhvFLwyiyF93eNwobA 0Q==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 3275cm4v50-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 14 Jul 2020 11:52:53 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06EBlXKw051230; Tue, 14 Jul 2020 11:50:53 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 327qb3tpgg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Jul 2020 11:50:52 +0000
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 06EBoq2F004212; Tue, 14 Jul 2020 11:50:52 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Jul 2020 04:50:52 -0700
From: Chuck Lever <chuck.lever@oracle.com>
Message-Id: <A67E2BFD-2038-4D7F-A42F-EE752A3B3FE7@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC06E857-C1A3-45AE-B417-C7D27DA82E31"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 14 Jul 2020 07:50:50 -0400
In-Reply-To: <CAM4esxTz0uzVQmGFLtzoXtyiU=aZCZRKeoyh18THCjJWSU7hNg@mail.gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, nfsv4-chairs <nfsv4-chairs@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, The IESG <iesg@ietf.org>, nfsv4@ietf.org
To: Martin Duke <martin.h.duke@gmail.com>
References: <159311856977.23665.6882641799899154823@ietfa.amsl.com> <20200708052747.GE16335@kduck.mit.edu> <CAM4esxTz0uzVQmGFLtzoXtyiU=aZCZRKeoyh18THCjJWSU7hNg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9681 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 mlxscore=0 spamscore=0 phishscore=0 suspectscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140090
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9681 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 bulkscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140090
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/FA8u5mhzWr-orxvoR3ukLu1E4pk>
Subject: Re: [nfsv4] Martin Duke'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, 14 Jul 2020 11:52:59 -0000

To address this issue, I've added the following text (in italics) to the
Security Considerations section.

   One purpose of the mechanism described in the current document is to
   protect RPC-based applications against threats to the confidentiality
   of RPC transactions and RPC user identities.  A taxonomy of these
   threats appears in Section 5 of [RFC6973].  Also, Section 6 of
   [RFC7525] contains a detailed discussion of technologies used in
   conjunction with TLS.  Implementers should familiarize themselves
   with these materials.

   Once a TLS session is established, the RPC payload carried on TLS
   version 1.3 is forward-secure.  However, implementers need to be
   aware that replay attacks can occur during session establishment.
   Remedies for such attacks are discussed in detail in Section 8 of
   [RFC8446].  Further, the current document does not provide a profile
   that defines the use of 0-RTT data (see Appendix E.5 of [RFC8446]).
   Therefore, RPC-over-TLS implementations MUST NOT use 0-RTT data.


> On Jul 8, 2020, at 9:50 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Thank you for that reference.
> 
> I agree that simply saying that Early Data MUST NOT be used is sufficient. I am skeptical that implementers of this draft will read E.5 of RFC 8446.
> 
> On Tue, Jul 7, 2020 at 10:27 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Thu, Jun 25, 2020 at 01:56:10PM -0700, Martin Duke via Datatracker wrote:
> > Martin Duke 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:
> > ----------------------------------------------------------------------
> > 
> > This presumably a trivial fix but I think it's important enough to be a DISCUSS:
> > 
> > I think the document needs some discussion of the security properties of TLS1.3
> > early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) and
> > mention that it is not forward-secure, unlike the rest of the payload.
> 
> I actually think that the situation is well-defined without such additional
> text -- Appendix E.5 notes that:
> 
>    Application protocols MUST NOT use 0-RTT data without a profile that
>    defines its use.  That profile needs to identify which messages or
>    interactions are safe to use with 0-RTT and how to handle the
>    situation when the server rejects 0-RTT and falls back to 1-RTT.
> 
> Since this document does not provide such a profile, early data MUST NOT be
> used, and there's no need to say more.

--
Chuck Lever