Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
David Noveck <davenoveck@gmail.com> Wed, 26 August 2020 18:21 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 8F1FA3A196C; Wed, 26 Aug 2020 11:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y92q0gWaomsR; Wed, 26 Aug 2020 11:21:45 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 B085E3A196A; Wed, 26 Aug 2020 11:21:44 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id d11so4140083ejt.13; Wed, 26 Aug 2020 11:21:44 -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=wGIJ+en2tRxtDTmBlhZSOYJ2q30OtlQFQEZbteN96VI=; b=WRvqxoo/2tBtUzngsZakzRa8bVq9Gw1P07emvKPlMJ49+AXnQevmARPT9s/+V2TChD XTPFL5mIqSSDv2V5IkQJfWS34oVufV+/G7c7Q98UwrAzIrnJAnFD/nGykRrZ+B4B/vyK teXBDVXIwnynJQ30jdtUJoNWV5ni+M3VnoqzfAhB26RKzSG53zTHt001usoS0Ad0GrXQ zpr7Xmap5Cq1pLLWUaijXvjYbWZr6A1j10HkOAvWUdksJumidqYttf2Eav74GD+Xo3rW ADeAmMuAtdzjj8QQ6CDnRmMzE0qVribsIFAr+Rczbx5Hf2+LAumDTCdK2AyZppw7X/Dp H/FA==
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=wGIJ+en2tRxtDTmBlhZSOYJ2q30OtlQFQEZbteN96VI=; b=HE2Ns+Eul6kHWH2D/6qXNUd8ZpTZE3kYYcLYTzxzEsYPvR/n64VyxV+jO0724OmeC8 GarFjpFEl57pwa0gM3c0p+mFkKUCSC0QpeS6FgMHxfHVHPLoBhFcASf6LHbDh3gMn0bN +pqcXLAhHKFyqZS69DEHtMEaHWAeZcQCrhvHk2EziIIiuQjVUHk8zyN6Ik6PHHO0tdiE YCROHdQBlNwvI0JrI72nRrBGinO9lkf8oFmtdV+Db1HGG44TEr9xo0VjpTNmg3iK4Mbv O8qllNI7q1LK5LWULgIb998QNt7TneaJjC2INdAyt2rW5t2EtpG9Kz/n6O+WnpeAt+9q LIzg==
X-Gm-Message-State: AOAM531oVSOy1OLjtvhuwVroJlDckBmytBymQ0GiXfopJOmS2vuAcswo ynK7czqfOIsdQy1An5OPBTatX8dB3VKGyruN45M=
X-Google-Smtp-Source: ABdhPJzTnLlvANJwOdBLwfxBDdHfc+rptZn6oE5aJosftmCzNKtj78+d0v3+lnjkFYcfDPRagXD/G6WcfZfL9cBnS+k=
X-Received: by 2002:a17:907:264b:: with SMTP id ar11mr12958229ejc.144.1598466103025; Wed, 26 Aug 2020 11:21:43 -0700 (PDT)
MIME-Version: 1.0
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com> <9BEC1316-A219-408F-AB27-74B28D702148@oracle.com> <0B907D1D-5818-46F7-9ADE-091D945A2A32@oracle.com> <CADaq8jejNL3NRVRi7DSD6TOK_0e6UOWZt=gt+kzCZL8JUO8kzA@mail.gmail.com> <7962DB37-E760-4A8C-8AE8-F1161D3E61BF@oracle.com>
In-Reply-To: <7962DB37-E760-4A8C-8AE8-F1161D3E61BF@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 26 Aug 2020 14:21:31 -0400
Message-ID: <CADaq8jcecSj6u8J8hAn0rPSDBzwe4r165UK6zO71bhBdDN-7kg@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041a40b05adcbe4a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/bcM78MJY6u77CV7CrY9gMU9sIyI>
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, 26 Aug 2020 18:21:48 -0000
On Wed, Aug 26, 2020 at 1:58 PM Chuck Lever <chuck.lever@oracle.com> wrote: > > > > On Aug 24, 2020, at 4:40 PM, David Noveck <davenoveck@gmail.com> wrote: > > > > > > > > On Mon, Aug 24, 2020 at 12:49 PM Chuck Lever <chuck.lever@oracle.com> > wrote: > > Hi nfsv4- > > > > The latest updates to address Roman Danyliw's ballot comments have > > been pushed to: > > > > https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html > > > > Before I can reach closure on these comments, I'm still in need of > > guidance for resolving the following issues with Section 5.2.2 of > > rpc-tls. > > > > (Ben's DISCUSS still remains. I plan to address those when closure > > on Roman's comments has been reached). > > > > > > > On Jul 8, 2020, at 11:43 AM, Chuck Lever <chuck.lever@oracle.com> > wrote: > > > > > > 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.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. > > > > Token Binding (Section 5.2.4) has been removed. However, Roman's > > comment still stands for Certificate Fingerprints (Section 5.2.2). > > > > Can anyone help? > > > > I'll try to help. > > > > > > > > >> ** 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. > > > > That's putting it mildly. The whole thing is kind of Sisyphean :-( > > > > Originally the document required SHA-1, as > > > it is the de facto standard algorithm for certificate fingerprinting. > > > > That doesn't count for much. After all, the de facto standard for NFS > authentication is AUTH_SYS. > > > > However, > > > subsequent security review pointed out that SHA-1 is deprecated. > > > > I can see that it would be hard to get this accepted without the > ability to the ability to argue cogently that SHA-1 weaknesses are not > relevant in this case. > > > > > > > > I changed the requirement to SHA-256, but this is problematic: most > fingerprint > > > implementations I'm aware of use SHA-1. > > > > It appears it is too insecure to get through the IESG but not so > insecure that people have stopped using it. > > > > 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. > OK, but that doesn't mean the IESG will accept it. Go ahead if you want to try it but if they object there is no point in continuing to knock your head against the wall. > > > > > 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. > > > > I can see the "or stronger" being an issue. It is often the case that > it is not completely clear whether A is stronger than B. > > Yes, "or stronger" was Gen-ART reviewer's complaint. I largely agree > that the phrase is weasel-y. > > > > > Suggesting that the document would need to provide a fixed list of > particular > > > algorithms here, rather than an open-ended requirement. > > > > The only issue I see if you can get a list including SHA-1 accepted. > > I'm not sure that a list of digest algorithms is the right answer. > OK, If you think one will do, go for it. > > SHA-1 seems to be what everyone uses, and I haven't found any public > document that states clearly that SHA-1 is not adequate for certificate > fingerprinting. > > Even RFC 4387 (in Section 2.2) defines a certificate fingerprint as the > SHA-1 hash of a certificate. > That document was published fourteen years ago. Perhaps it needs to be updated but we don't want to have to wait for that. > > > > It is easier than SHA-1 alone but not a sure bet. you might be able to > sell it as a stop-gap, if there are ways to upgrade it later, especially if > this is part of pushing AUTH-SYS towards the scrapheap of history. > > > > SHA-1 + SHA-256 is one possible list. The other is to include > everything within the secure hash standard. > > Can you provide a reference to "the secure hash standard?" https://www.nist.gov/publications/secure-hash-standard If that points > to an RFC that can be obsoleted, that could be adequate. But again, I'm > not sure that's the right thing to do if everyone else feels SHA-1 is > adequate for the purpose of fingerprinting x.509 certificates. > I don't know what everyone else feels about this issue. I don't a have real opinion as to SHA-1's adequacy for this purpose so I'm anxious about relying on SHA-1 with no fallback. > > > > I'm think of rpc-tls allowing other layers in the stack to impose > further restrictions on the algorithm to be used, e.g. > > • Allowing ULPs to require specific hash algorithms. This would > allow us to get rpc-tls out now and upgrade it when > draft-ietf-nfsv4-security is out. > > • Allowing RPC to require specific hash algorithms when used for > particular purposes such as verifying the identity of a client host using > AUTH_SYS. This would allow us to get rpc-tls out now and upgrade it > when an update to RFC5531 dealing with AUTH_SYS is out. > > > > > -- > 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