Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Mon, 17 February 2020 16:55 UTC

Return-Path: <tigran.mkrtchyan@desy.de>
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 4C2DB120850 for <nfsv4@ietfa.amsl.com>; Mon, 17 Feb 2020 08:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6
X-Spam-Level:
X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
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 qkvwY1022E50 for <nfsv4@ietfa.amsl.com>; Mon, 17 Feb 2020 08:55:23 -0800 (PST)
Received: from smtp-o-1.desy.de (smtp-o-1.desy.de [131.169.56.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61575120841 for <nfsv4@ietf.org>; Mon, 17 Feb 2020 08:55:23 -0800 (PST)
Received: from smtp-buf-1.desy.de (smtp-buf-1.desy.de [IPv6:2001:638:700:1038::1:a4]) by smtp-o-1.desy.de (Postfix) with ESMTP id 9060EE011B for <nfsv4@ietf.org>; Mon, 17 Feb 2020 17:55:20 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-1.desy.de 9060EE011B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1581958520; bh=eG68U48mdUNOoZHWFUs5YySbCiH8pilJ26xyKBADc5c=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=di6yf2nJxVGDP3yzgBFYR9wu+411w6D7sMpUPxtrrqZ7ky3a14HPYXaUgxchHgaJB puC7MIF88SFVXAS2s+IURGq5gxcp9tdM6Ry5d8oTYflKJyLglJ/Fy8o80CBBhjSMVP cuzELqDxoIpoyWrv0jdUu3VgthvrA16h2109YBKs=
Received: from smtp-m-1.desy.de (smtp-m-1.desy.de [131.169.56.129]) by smtp-buf-1.desy.de (Postfix) with ESMTP id 8AC45120260; Mon, 17 Feb 2020 17:55:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-1.desy.de (Postfix) with ESMTP id 5DA35C04EB; Mon, 17 Feb 2020 17:55:20 +0100 (CET)
Date: Mon, 17 Feb 2020 17:55:20 +0100 (CET)
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>
Message-ID: <1689124047.6528394.1581958520001.JavaMail.zimbra@desy.de>
In-Reply-To: <255FD5F9-7256-4C1F-B562-C078C73857B5@oracle.com>
References: <158074451013.28494.10714680016688772019@ietfa.amsl.com> <4F4B842E-86BB-46BF-92F4-B81ECDDCCD05@oracle.com> <1596201389.6225924.1581770847254.JavaMail.zimbra@desy.de> <255FD5F9-7256-4C1F-B562-C078C73857B5@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Mailer: Zimbra 8.8.15_GA_3888 (ZimbraWebClient - FF73 (Linux)/8.8.15_GA_3890)
Thread-Topic: I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt
Thread-Index: woMpF1KHaXvYC1GE3vvPGnlmLXCi4g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/72HlIddrWp5P_enruXOwicRFKjc>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt
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: Mon, 17 Feb 2020 16:55:28 -0000

Hi Chuck,

I will try provide some text to address this issue.

Thanks,
   Tigran.


----- Original Message -----
> From: "Chuck Lever" <chuck.lever@oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> Cc: "NFSv4" <nfsv4@ietf.org>
> Sent: Saturday, February 15, 2020 5:02:43 PM
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt

> Hi Tigran-
> 
> Opened https://github.com/chucklever/i-d-rpc-tls/issues/8 to track
> this.
> 
>> On Feb 15, 2020, at 7:47 AM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
>> 
>> Hi Chuck,
>> 
>> Yesterday we were fixing in our (not nfs related) code a TLS bug.
>> The issue was that we were redirecting clients to another endpoint
>> by an IP address. As a result, the client side server certificate
>> validation was failing, as subject alternative name didn't match
>> endpoint client was connecting to - subject and and alternative
>> name were dns names.
>> 
>> This situation is very similar to what we will ger with pNFS, where
>> data servers are offered as combination of netid and uaddr.
> 
> I'm thinking fs_locations too, but agreed.
> 
> 
>> Though
>> there is no direct connection between your spec and pNFS over TLS,
>> you probably should have a paragraph describing TLS and certificate
>> handling when server address presented as netid+uaddr.
> 
> I was wondering if this should be in a later NFS-related document,
> but both netid and uaddr are RPC-layer data types.
> 
> Would you propose some text to get us started? Describe how you
> addressed the bug, for example. What do you think are the
> interoperability concerns?
> 
> 
>> Regards,
>>   Tigran.
>> 
>> 
>> ----- Original Message -----
>>> From: "Chuck Lever" <chuck.lever@oracle.com>
>>> To: "NFSv4" <nfsv4@ietf.org>
>>> Sent: Monday, February 3, 2020 4:44:11 PM
>>> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt
>> 
>>>> On Feb 3, 2020, at 10:41 AM, internet-drafts@ietf.org wrote:
>>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Network File System Version 4 WG of the IETF.
>>>> 
>>>>       Title           : Towards Remote Procedure Call Encryption By Default
>>>>       Authors         : Trond Myklebust
>>>>                         Charles Lever
>>>> 	Filename        : draft-ietf-nfsv4-rpc-tls-06.txt
>>>> 	Pages           : 21
>>>> 	Date            : 2020-02-03
>>>> 
>>>> Abstract:
>>>>  This document describes a mechanism that, through the use of
>>>>  opportunistic Transport Layer Security (TLS), enables encryption of
>>>>  in-transit Remote Procedure Call (RPC) transactions while
>>>>  interoperating with ONC RPC implementations that do not support this
>>>>  mechanism.  This document updates RFC 5531.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>>>> 
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-06
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-06
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-06
>>>> 
>>>> 
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> I heard no objection to the changes proposed last week.
>>> This revision addresses recent comments from Rick Macklem.
>>> 
>>> 
>>> --
>>> Chuck Lever
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever