Return-Path: 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 Message-Id: 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: Cc: Benjamin Kaduk , nfsv4-chairs , draft-ietf-nfsv4-rpc-tls@ietf.org, The IESG , nfsv4@ietf.org To: Martin Duke References: <159311856977.23665.6882641799899154823@ietfa.amsl.com> <20200708052747.GE16335@kduck.mit.edu> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 11:52:59 -0000 --Apple-Mail=_DC06E857-C1A3-45AE-B417-C7D27DA82E31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > Thank you for that reference. >=20 > 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. >=20 > On Tue, Jul 7, 2020 at 10:27 PM Benjamin Kaduk 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 > >=20 > > 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.) > >=20 > >=20 > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/ > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > >=20 > > This presumably a trivial fix but I think it's important enough to = be a DISCUSS: > >=20 > > 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. >=20 > I actually think that the situation is well-defined without such = additional > text -- Appendix E.5 notes that: >=20 > 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. >=20 > 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 --Apple-Mail=_DC06E857-C1A3-45AE-B417-C7D27DA82E31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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



= --Apple-Mail=_DC06E857-C1A3-45AE-B417-C7D27DA82E31--