Re: [nfsv4] Erik Kline's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)
Erik Kline <ek.ietf@gmail.com> Fri, 03 July 2020 20:44 UTC
Return-Path: <ek.ietf@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 274043A0E50; Fri, 3 Jul 2020 13:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 dcQIjRhg66ME; Fri, 3 Jul 2020 13:44:01 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 B69AF3A0E4F; Fri, 3 Jul 2020 13:44:00 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id w17so26721894oie.6; Fri, 03 Jul 2020 13:44:00 -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=YjxKEEIEZLhoi1rv94ATV9heoxgRXNL4BwZ5DNDyIzM=; b=p398Ocfqfy7qeSTjxB2JiPmdYUb3HLPryym9DemiWbJPRS4sWXuBFndMKMEtvHwHvs CxKVzrmCVHNVQOzvCQczq3hdMnrd6iCGgJM7rYNvcf61T4Iynzm5XZwnyUo+6zFS8FQs f6o0u4jU6V3/JQ/vXjGJbqWDix2Fs1LpZ4C5WRMMyk87i/aHZ7lUl9TUsgYGtE/UUQcn Oi/l3BXJ92gfRvfxNrxtefwT+tineHyN/4aRmnHaJXQ0LBuSphX6b4ssympC1bDYF5px dfmYn3bxVGHFA54zHnA5s6pdchzNA/lZMr+fDHQubKx7Eyx93C7cmz9PzIM5h0rh2buS 5SUg==
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=YjxKEEIEZLhoi1rv94ATV9heoxgRXNL4BwZ5DNDyIzM=; b=axpBXqTXe92e8K/oo6b/r8+gWghGdTz16UrkGFk3iHZZ5hQWoszN9k/JxJFt3of3Di DLuUGSOV0ubhbKCJDn/Oi6kXn5kkZBuUerc81cwbXvS5hxJQPQIxyrhryRuuvXoJ8K/g nnJs81Nc8gwddkKjQz+3h4KeQORZESHTBqdUGcYybrH8q4ZR7eM9UQJPWXMIiRUdagRQ PzHkoZA57c715TdYxHqkCxhTGD3Es1h7R0GTDypctnFWizSQyu5IHRA8B5MzxJqkdNoO xh8AXssLJJjqyISGimIexn9FOflFt7PIHM6uZo3RW2sb0XW9lFSiJ8rCbwVAfbNk61t2 r7NQ==
X-Gm-Message-State: AOAM533aU1sR+3GUTVAJ5g2yYcn57wdEBHOi0Dx6ukrUuXL7NncmVmVx FZVBTNr7WSAgIvoYavRXaHkEcpYT7Odmnz6aVag=
X-Google-Smtp-Source: ABdhPJwSPE7m+YIWRUYs9vsHD5qiQPYXzDg5GdFS10v4XCDtIbNKcovpNXhfACFQcZkaKyALvW2AKkf0MJDS9p3yfek=
X-Received: by 2002:aca:494d:: with SMTP id w74mr24024572oia.97.1593809040046; Fri, 03 Jul 2020 13:44:00 -0700 (PDT)
MIME-Version: 1.0
References: <159349149991.12516.12036430886387047884@ietfa.amsl.com> <FEE410F9-240F-4401-99CF-A2FC54DFE095@oracle.com> <CAMGpriWpER-pzH+Nfer=OSZKbU-cUJ9Arqsk1rxZU-72dWy1sg@mail.gmail.com> <AA6DCFBF-2B7E-45FE-B770-22B4E3B68446@oracle.com> <CAMGpriV3F2f+Tk8QWaWie4DB55on0rG7Knip+bAvZzZyBR+T3Q@mail.gmail.com> <37E9EC4E-938D-4986-895F-8EFA85469DB1@oracle.com> <A70A21D0-D54F-4259-9D13-B7123BFBA928@oracle.com>
In-Reply-To: <A70A21D0-D54F-4259-9D13-B7123BFBA928@oracle.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Fri, 03 Jul 2020 13:43:46 -0700
Message-ID: <CAMGpriVZvrsjw23AdfcBbs4b+XLGj2b8WXhDf86WryJ=XhU8FA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, David Noveck <davenoveck@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/jz6GR4S3xbFfbymzZjbjWXHMdU4>
Subject: Re: [nfsv4] Erik Kline's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with 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, 03 Jul 2020 20:44:02 -0000
On Fri, Jul 3, 2020 at 8:57 AM Chuck Lever <chuck.lever@oracle.com> wrote: > > > > > On Jul 2, 2020, at 2:26 PM, Chuck Lever <chuck.lever@oracle.com> wrote: > > > >> On Jul 2, 2020, at 2:08 PM, Erik Kline <ek.ietf@gmail.com> wrote: > >> > >> I was more curious about text for how a TCP RPC server identifies TLS > >> ClientHello from the first of possibly several unencrypted RPCs after > >> the 3WHS. And it seems like the same "try to parse a ClientHello else > >> try to parse an ONC RPC message" is the recommended approach > >> (analogous to DTLS above)? It was a statement to this effect that I > >> was after. > > I propose updating the first paragraph of Section 5.1.1: > > OLD: > > The use of the Transport Layer Security (TLS) protocol [RFC8446] > protects RPC on TCP connections. Typically, once an RPC client > completes the TCP handshake, it uses the mechanism described in > Section 4.1 to discover RPC-over-TLS support for that connection. If > spurious traffic appears on a TCP connection between the initial > clear-text AUTH_TLS probe and the TLS session handshake, receivers > MUST discard that data without response and then SHOULD drop the > connection. > > NEW: > > The use of the Transport Layer Security (TLS) protocol [RFC8446] > protects RPC on TCP connections. Typically, once an RPC client > completes the TCP handshake, it uses the mechanism described in > Section 4.1 to discover RPC-over-TLS support for that connection. > Until an AUTH_TLS probe is done on a connection, the RPC server > treats all traffic as RPC messages. If spurious traffic appears on a > TCP connection between the initial clear-text AUTH_TLS probe and the > TLS session handshake, receivers MUST discard that data without > response and then SHOULD drop the connection. Ah, I failed to properly grasp that this needs to happen for each and every new TCP connection. I had assumed (for no good reason whatsoever) that the AUTH_TLS-ability of a server TCP endpoint could be cached for subsequent connection speedup. If that's not happening then this all makes sense. I apologize for my confusion and I do like this new text -- it helps hammer home the point. Thanks again.
- [nfsv4] Erik Kline's No Objection on draft-ietf-n… Erik Kline via Datatracker
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Chuck Lever
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Erik Kline
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Chuck Lever
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Erik Kline
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Chuck Lever
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Chuck Lever
- Re: [nfsv4] Erik Kline's No Objection on draft-ie… Erik Kline