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

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Wed, 08 July 2020 20:02 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 236533A07A8 for <nfsv4@ietfa.amsl.com>; Wed, 8 Jul 2020 13:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 djOp8f1agNOS for <nfsv4@ietfa.amsl.com>; Wed, 8 Jul 2020 13:02:35 -0700 (PDT)
Received: from smtp-o-1.desy.de (smtp-o-1.desy.de [IPv6:2001:638:700:1038::1:9a]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A893A07A2 for <nfsv4@ietf.org>; Wed, 8 Jul 2020 13:02:34 -0700 (PDT)
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 36084E070E for <nfsv4@ietf.org>; Wed, 8 Jul 2020 22:02:32 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-1.desy.de 36084E070E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1594238552; bh=Xa9J8Ooba7fzelnQX0vUeo7LVQd8qZPQNYtM5QoDCMM=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=R5D2JvuSm3iwLn91rSrOdHR9RH9VQWkAk5bjwj6Iwvdf7rqO3rTvM1PS2RlORavWV xcTud8b3Ao8fOleDIMzdCOUXg6myr7xyjqufIhG1FQF+m467wFi8aH+0oauMFUL4lQ o18rklcOC1dCmO8bI8s8fL4yl/YiJAPu8wa61sVY=
Received: from smtp-m-1.desy.de (smtp-m-1.desy.de [IPv6:2001:638:700:1038::1:81]) by smtp-buf-1.desy.de (Postfix) with ESMTP id 25DE51201D4; Wed, 8 Jul 2020 22:02:32 +0200 (CEST)
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-2.desy.de (Postfix) with ESMTP id EF5F410007B; Wed, 8 Jul 2020 22:02:31 +0200 (CEST)
Date: Wed, 8 Jul 2020 22:02:31 +0200 (CEST)
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>, NFSv4 <nfsv4@ietf.org>, Chuck Lever <chuck.lever@oracle.com>
Message-ID: <143244284.2221159.1594238551646.JavaMail.zimbra@desy.de>
In-Reply-To: <9BEC1316-A219-408F-AB27-74B28D702148@oracle.com>
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com> <9BEC1316-A219-408F-AB27-74B28D702148@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: Zimbra 8.8.15_GA_3901 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3895)
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
Thread-Index: zmZhwEDqQb5oor9jcdWOucuj9zlDyQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/JmEDpeiSrTTjUOhfXKVjw1eeWO8>
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: Wed, 08 Jul 2020 20:02:37 -0000

Hi Roman,

----- Original Message -----
> From: "Chuck Lever" <chuck.lever@oracle.com>
> To: "Roman Danyliw" <rdd@cert.org>rg>, "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> Cc: "The IESG" <iesg@ietf.org>rg>, draft-ietf-nfsv4-rpc-tls@ietf.org, "nfsv4-chairs" <nfsv4-chairs@ietf.org>rg>, "NFSv4"
> <nfsv4@ietf.org>
> Sent: Wednesday, July 8, 2020 5:43:57 PM
> Subject: Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

> Hi Roman-
> 
> Here are my responses to your COMMENTs in Section 5.
> 
> 
>> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <noreply@ietf.org>
>> wrote:
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> ** Section 5.2.1.  Per “For services accessed by their network identifiers
>> (netids) and universal network addresses (uaddr), the iPAddress subjectAltName
>> SHOULD be present in the certificate and must exactly …”, why not a normative
>> MUST?
> 
> This language came from Tigran Mkrtchyan. Tigran, can you comment?

The MUST implies that protocol require client to reject the connection to a server
which doesen't provide ipAddress, however, with SHOULD protocol delegates the decision
to the application, similar to how one can pass `-k` option to curl to bypass
certificate validation.

@Chuck
Feel free to change it to MUST, if it's more appropriate.

Thanks, 
   Tigran.

> 
> 
>> ** Section 5.2.1.  Per “For example, if the Issuer is not in a trusted set of
>> Issuers, the RPC server may decline to perform RPC transactions with this
>> client.”, wouldn’t the TLS connection fail in this case and not even get to
>> whatever authorization logic the RPC server might have?
> 
> I can remove this sentence.
> 
> 
>> ** Section 5.2.1.  Per “As a suggestion, at least the following parameters of
>> the X.509 client certificate SHOULD be exposed … Originating IP address”, how
>> exactly should this IP address be exposed in the certificate, or is this
>> intended to be the IP address of the peer which presented the certificate?
> 
> I believe this is the IP address of the peer which presented the certificate.
> 
> 
>> ** Section 5.2.2 and 5.2.4.  Both 5.2.1 and 5.2.3 described what information
>> should be exposed by implementations.  These sections omit that information.
>> For example, I would have expected Section 5.2.4 to discuss Token Binding IDs
> 
> PSK and Token Binding were added on request, and no further details were
> provided
> by the requesters.
> 
> 
>> ** Section 5.2.2.  Is there any MTI guidance on the kinds of digests to support
>> for these fingerprints?
> 
> I've had some difficulty with this. Originally the document required SHA-1, as
> it is the de facto standard algorithm for certificate fingerprinting. However,
> subsequent security review pointed out that SHA-1 is deprecated.
> 
> I changed the requirement to SHA-256, but this is problematic: most fingerprint
> implementations I'm aware of use SHA-1. I have found no published document that
> suggests that SHA-1 is a problem for certificate fingerprinting, and no standard
> that specifically discusses certificate fingerprinting algorithms.
> 
> During Gen-ART review, the reviewer complained about the comparative:
> 
>  Implementations MUST support SHA-256
>  [FIPS.180-4] or stronger as the hash algorithm for the fingerprint.
> 
> Suggesting that the document would need to provide a fixed list of particular
> algorithms here, rather than an open-ended requirement. I punted and removed
> the sentence.
> 
> I'm not sure how to proceed.
> 
> 
>> ** Section 5.2.4.  Are there any MTI parameters for the token binding to
>> specify?
> 
> After reviewing RFC 8473, it appears that more changes to the RPC protocol would
> be necessary to support Token Binding. Thus perhaps support for token binding in
> this context should be deferred to a separate document. Can anyone with more
> domain expertise comment?
> 
> 
> --
> Chuck Lever