IETF Logo Mail Archive

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

v2.8.10 | Report a Bug | By Email