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

Chuck Lever <chuck.lever@oracle.com> Fri, 21 August 2020 20:49 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 E66183A12D5; Fri, 21 Aug 2020 13:49:18 -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 N1UwS1UrHzJp; Fri, 21 Aug 2020 13:49:17 -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 B5C313A1260; Fri, 21 Aug 2020 13:49:13 -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 07LKlZ6t049832; Fri, 21 Aug 2020 20:49:07 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=fykhp3JcpKUR7xZ2hi+KpO3ce6Uu+55Hs9/PR6yieCk=; b=psy3chu9meDu2TTlsyYA7xZpddcECXb1o0p+sdiP+/72lmOACYklJwP5yvS7EKF0qzb/ rMDU247ZtyZ0QooFym68/wRdYSnNRvIMfhG4QInY5g87/Yci/zr85KCgT4/2JeeK+n5a 3JbPdl9RztMJWldqcNVt0c6HMQthVVRezI9h5UtWdRwdinnWEsGep8DujL/EPZ5+bRyI qKbKWE4wS7kHwKm3/puCjPUDWKzj1fUO6T5XVt9i3wwGV0r1XRBEM7YOw8FJ+VVokVI3 CQ4qFxgesI20QAxMVW1g1O417NN7xb422OcbB1DZt4znXIbW1NWT/AcxgbL4UhdMFHcF aQ==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 3322bjmh6k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Aug 2020 20:49:07 +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 07LKhwOb170715; Fri, 21 Aug 2020 20:47:07 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 330pvsmd1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Aug 2020 20:47:07 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 07LKkxLM008457; Fri, 21 Aug 2020 20:46:59 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Aug 2020 20:46:59 +0000
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: <de856156e0dc4eaca3c00fe1bdf998ef@cert.org>
Date: Fri, 21 Aug 2020 16:46:58 -0400
Cc: David Noveck <davenoveck@gmail.com>, The IESG <iesg@ietf.org>, Roman Danyliw <rdd@cert.org>, "draft-ietf-nfsv4-rpc-tls@ietf.org" <draft-ietf-nfsv4-rpc-tls@ietf.org>, nfsv4-chairs <nfsv4-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6568ECB3-A6AB-44F2-9F09-16EDE8F8381B@oracle.com>
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com> <18B68FBF-34A1-4F8F-A0E3-4A88ABAAF900@oracle.com> <F9231574-4E6B-49F2-A752-085C5A58C561@oracle.com> <93A02493-3212-4474-994F-7345409D6499@oracle.com> <CADaq8jc+=Q65wif8w9g9g9-vkzfZqWHMG3xDuuZAfZ6NFhmE4A@mail.gmail.com> <de856156e0dc4eaca3c00fe1bdf998ef@cert.org>
To: NFSv4 <nfsv4@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9720 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 phishscore=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxlogscore=938 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008210193
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9720 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 adultscore=0 mlxscore=0 mlxlogscore=932 phishscore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008210194
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/1rS3BfMg4-0vMOs4CyIMCGeXiXU>
Subject: Re: [nfsv4] Roman Danyliw'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: Fri, 21 Aug 2020 20:49:26 -0000

To the WG:

> On Aug 21, 2020, at 3:45 PM, Roman Danyliw <rdd@cert.org> wrote:
> 
> >>> -- Section 5.2.4.  The token binding mechanism suggested here, RFC8471, only
> >>> applies to TLS v1.2.  The expired draft-ietf-tokbind-tls13 provides the TLS
> >>> v1.3 mechanism.
> >> 
> >> Potential replacement:
> >> 
> >> OLD:
> >> 
> >> 5.2.4.  Token Binding
> >> 
> >>  This mechanism is OPTIONAL to implement.  In this mode, a token
> >>  uniquely identifies the RPC peer.
> >> 
> >>  Versions of TLS after TLS 1.2 contain a token binding mechanism that
> >>  is more secure than using certificates.  This mechanism is detailed
> >>  in [RFC8471].
> >> 
> >> NEW:
> >> 
> >> 5.2.4.  Token Binding
> >> 
> >>  This mechanism is OPTIONAL to implement.  In this mode, a token
> >>  uniquely identifies the RPC peer.  The TLSv1.3 token binding
> >>  mechanism is detailed in [I-D.ietf-tokbind-tls13].
> >> 
> >> 
> >> Another option would be to remove this section.
> 
> 
> I leave this up to the working group/responsible AD to sort out.  My DISCUSS is on the fact this this behavior needs to be specified for TLS v1.3 not on how it gets documented.  My recommendation would be to remove the section – there is no IETF consensus reference for this behavior.  This binding can always be specified later.  If there is a desire to use ietf-tokbind-tls13 and there is work planned to publish it (i.e., pull it out of expired state and iterate to completion), this document could also wait in a MISREF state with the RFC Editorial until it is published.  I suspect there is also the option of re-calling consensus on the document for a downref to an unpublished document.  I’m flexible.

It seems to me that leaving this section in place introduces an
indeterminate delay before publication. At this point my preference
would be to remove all discussion of token binding, since it's not
clear when TLS v1.3 will properly support it.

Is there any objection to removal?


--
Chuck Lever