Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
David Noveck <davenoveck@gmail.com> Sat, 22 August 2020 08:50 UTC
Return-Path: <davenoveck@gmail.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 918AD3A1089;
Sat, 22 Aug 2020 01:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 QBdkQ8iajWKc; Sat, 22 Aug 2020 01:50:11 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
[IPv6:2a00:1450:4864:20::62b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 6BE983A0E2F;
Sat, 22 Aug 2020 01:50:10 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id g19so5288244ejc.9;
Sat, 22 Aug 2020 01:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=f7H+RRBk3i9kPkGhpNvzi3ScoYhIzRTd/rFPzLSzJQI=;
b=dordLl529LK3Pw1sqa9Jgj4FTnVf6rCDzHUudxMxI4V1SraWAcTahElyVSv0AWZ1Xf
WNXk8NduG032U3+UD2cTgABGQpai8QHsMz3IIc4rmACJwMEF0SFWkqZ86EZNHRPGyOh8
SI+qs9tYUkZQx/NQItfVo+m6jSz0CPDkwXGii2nOGEqmDHYDRVZo8Tq7sQ4UV2mm0gD/
fu1EppoZW4ZEm5fcNcqEf24J1bbyw2lssrSbxXYt7/lbUClAWl9/XVAb71StzB7dO56L
5lhRevr5o36mpoHNmnv5ZGADgak9htCkp0ieDo1jR84a1hyA6fcMR0AT6pY+wNriJVak
WfRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=f7H+RRBk3i9kPkGhpNvzi3ScoYhIzRTd/rFPzLSzJQI=;
b=aL6mdumh84D2YGdG2R2JhRTLP6nCGjrv7s6ZwHHu259Dsdi47MbAm1TquQZrYC2Jln
UVK8lxtTO7rKUX6YSof22dEXorR1jm5lU/l5q+TE44BKzyER6g9m/glBEJ0OssdVANP0
+NfKiHMQVv56zVr4Pi0d+gNLnid9iSExxU4vu6E4BwemnEI8RToELf6Ir6ffXzbCWs82
1gNYqcggD9sgcWWUWyAKefJfyYRAORluXmOx7Z86up2WHt2bsQrAloKbrxnVgUeZdJDw
QfFQijpeRGcn7PyrTQkN+e+StlfqvpAu0Btvzw4Js8d6fMRM9HHh8GWabADpgg3JNcLQ
8W1A==
X-Gm-Message-State: AOAM5319Mts4FmWkuoWl7lZ196YHo7fohTuwICGpadc4bhuMwn0BCy/9
VkDZjLfciY71dNXjq4C4btu12IGcTLWIUPs1qzQ=
X-Google-Smtp-Source: ABdhPJxkjZ9uR/hV3UL1YtghgxDyxJmuPnUrvxFEXGQ3MnkthrdiEZLtoNcqniPHBTN9M4SVUGaqGXrXpY63sfwMeoQ=
X-Received: by 2002:a17:906:fad1:: with SMTP id
lu17mr6491047ejb.127.1598086208737;
Sat, 22 Aug 2020 01:50:08 -0700 (PDT)
MIME-Version: 1.0
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>
<6568ECB3-A6AB-44F2-9F09-16EDE8F8381B@oracle.com>
In-Reply-To: <6568ECB3-A6AB-44F2-9F09-16EDE8F8381B@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 22 Aug 2020 04:49:56 -0400
Message-ID: <CADaq8jdfXiRV5awmw54U7PEBxt6HucjhK8TW55ft_UFwLKg+Jg@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>, 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-Type: multipart/alternative; boundary="000000000000cad7d305ad73700e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xyKM1rLEB5H6l3HbiNo0fiF8028>
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: Sat, 22 Aug 2020 08:50:13 -0000
no objection on my part. On Fri, Aug 21, 2020, 4:49 PM Chuck Lever <chuck.lever@oracle.com> wrote: > 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 > > > >
- [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfs… Roman Danyliw via Datatracker
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Mkrtchyan, Tigran
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… David Noveck
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… David Noveck
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… David Noveck
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… David Noveck
- Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf… Chuck Lever