From owner-freebsd-questions@freebsd.org Fri Nov 27 05:18:19 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2304D47D320 for ; Fri, 27 Nov 2020 05:18:19 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cj2vt30cbz4bnX for ; Fri, 27 Nov 2020 05:18:18 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ed1-x544.google.com with SMTP id n24so2308903edb.4 for ; Thu, 26 Nov 2020 21:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O7KMKQe71JL4Z1u/IPw2ePZbBEcuNmNe7sTziBHITpo=; b=AX6W7y4KwirnQsLCnMI2gKVkbUXH/1hQPoTRNZlR1C32QfTNx7dSupOtMMByVg0ps4 7S/fWuvWHX16dBp5k++3pUnteGSaqI8hIBPNga6KgaWdhZgcVYA1WEe9+wAZNEJXG3FY ahSJX5nwWQUNhy1KaLs3SNIEUvJcWe+kJdPLCvPqkDrqtWXBss7mlSdBjE32+IZZyrle ZPu9v4RK3hgDiOFxTomK6RzvaitVmvEZXgnrDGQdf8FtGYQ3nRzyg0uGV6t2XPRIkKzo CIICRK0wK/++O3IFY2T0Xt9Hym/hNBzYYZxnhiDmhxeZALdDVaJKFBesAF36v0153nvi 4jKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O7KMKQe71JL4Z1u/IPw2ePZbBEcuNmNe7sTziBHITpo=; b=hBPZH1ylYco/P/+iPJIs5rfMcw+vHPbtXpDzkJjw6V4Wr4+Ds/+6slIEbKknbCnrZU NJcCYi4Qv8QscKsATvuXT/Ya/eh+Dwkdl9hVQ+Rdw84uizHNTBDtFjjiCPx4Ug1HNS/N pHFTJc2miUNUXf+QhMZh4OoP4Netxl7akzCInCAERoxkcuPfn+SbbkDpAXTMfJE73JuQ zm+1s7qSussBOpW7Hl2ybA2zKk58t8GkqyumYElaeVkHMXKFOUDgII2UDqyhWYFAz6DM T8qELq0MjcjkRyhhCWCeMOaGMqmEg9A0cJGz0nvzn/7RC+FhJeIzhOwwteuvRejT0NQs sQqA== X-Gm-Message-State: AOAM532hQ/ndwb+gXt4U50VBt7eakaQ9CpsK4s2mbPZayYjHuHAWbZRk qe1Mm53CIaqU9YqK5QbgCDYBvl5MQU0B6mjscOA= X-Google-Smtp-Source: ABdhPJzkHoiVSH/YFCPnAMjT+a5KLbzkqtag0zKbD2bq/q+J8ZhhhA0x1zxpb5nOAzxAeS8cs8UlxM5W7N6wXOWIRB4= X-Received: by 2002:a50:b404:: with SMTP id b4mr5738834edh.369.1606454296714; Thu, 26 Nov 2020 21:18:16 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a50:344f:0:0:0:0:0 with HTTP; Thu, 26 Nov 2020 21:18:16 -0800 (PST) In-Reply-To: References: From: grarpamp Date: Fri, 27 Nov 2020 00:18:16 -0500 Message-ID: Subject: Re: [nfsv4] testing of RPC over TLS To: Rick Macklem Cc: nfsv4@ietf.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Cj2vt30cbz4bnX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=AX6W7y4K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::544 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::544:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::544:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::544:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 05:18:19 -0000 On 11/26/20, Rick Macklem wrote: > The implementation of RPC over TLS for freebsd is now basically > done and setting up a test system is fairly straightforward. Nice. > If you are interested see > https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt > > If you have any questions about it, feel free to ask, rick How do users and administrators pin down the public key fingerprint of the NFS server's TLS certificate so that the hash is checked and thus a MITM attack is prevented? >From March on list... Implementations must provide users with TLS public key fingerprint pinning options. Implementations that do not offer those options are exposing their users to MITM risks (those risks are not mitigated by the legacy wrong answer of 'trust the [rogue and or MITMable] "CA" system'). MITM attacks are in play by many parties over many networks. *ALL* applications that speak TLS today must make these pubkey fingerprint pinning options available for their users. Cheers. https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls People appear to be talking about using and "authenticating / verifying" TLS certs now with at least perhaps this NFSv4, and certainly with other apps. If so, it's required critical thing for the admins and users to have the option to pin the certificate pubkey fingerprints in four ways... - Ignore the CA chain / expiry / etc, validate only the fingerprint. - Validate the CA chain / expiry / etc, and validate the fingerprint. - Validate the CA chain / expiry / etc, ignore the fingerprint. - A TOFU mode, with some management by fingerprint options. No application that uses TLS should be considered completely featured and security capable without fingerprint pinning functions. The "SHOULD implement" loophole in 5.5.2 will end up with many OS and implementations lacking such basic security feature option. For some background reasons on why pubkey fingerprint pinning implementations are now showing up in softwares that speak TLS, and for sample code, and related infos, see the links... https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html --pinnedpubkey Tells curl to use the specified public key file (or hashes) to verify the peer. This can be a path to a file which contains a single public key in PEM or DER format, or any number of base64 encoded sha256 hashes preceded by 'sha256//' and separated by ';'. When negotiating a TLS or SSL connection, the server sends a certificate indicating its identity. A public key is extracted from this certificate and if it does not exactly match the public key provided to this option, curl will abort the connection before sending or receiving any data. Please note this option is rightly very specific covering only the isolated pubkey, not the DER form of the entire "CA signed" cert (ie: not the typically referenced coverage of "openssl x509 -fingerprint"). This allows additional adaptability to some cert environments. Complete fingerprint implementations need both modes: pubkey, and cert DER. Also note the use of sha-256, not the broken and now deprecated sha-1, sha-3 could function as a backstop. When fully implemented, fingerprint pinning enables a local admin and user environment of more flexible certificate validation service cababilities and security model hardening when subject to various third party things and adversaries like... - Environment of rogue / forced / spy MITM CA's, TLS termination / proxy cloud MITM, VPN / overlay / WiFi networks MITM, etc. - Annoying "expired" certs awaiting tax revenue from their captured audience. - Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google, and corporate schemes, to let edge server certs they sign be freely rotated and or freshly signed without need to update pin. - Avoid need to update pin every "expiry" period. - Avoid CA's by using cert owners publicly available and out of band self certified hash attestations found on keybase, social, observatories, PGP, etc. - As mentioned above, optionally in combination with other CA / expiry / etc checks, or ignoring the CA altogether. - CRL checks are a massive metadata privacy and user monetization leak that some users might not want exposed to. - Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint) Another very useful security feature to have is a trust on first use TOFU mode that stores, pins, and subsequently validates against those fingerprints, similar to SSH model. This is useful for both known comms partners such as client-server model, and in more distributed group or even p2p applications to help keep things a bit more locked down by default. Defense (like this pubkey fingerprint pinning) in depth... you can use it :) References (obviously TLS_1.3 is todays version to use)... https://www.netcraft.com/internet-data-mining/ssl-survey/ https://www.ssllabs.com/ssl-pulse/ https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/ https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/ https://en.wikipedia.org/wiki/Transport_Layer_Security https://tools.ietf.org/html/rfc8446 https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a31198d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3 https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf53691992/docs/TODO#L728 On 3/30/20, Black, David wrote: > This looks interesting - is there a BCP (Best Current Practice) RFC or > similar reference on what MUST/SHOULD to be implemented and how implementers > ought to think about this to make good choices? Or is there one being > prepared? Not aware of one, maybe the list knows of some more resources? Would be good to have some more documents in the space. In particular herein regarding fingerprinting... differentiating the two different cert DER vs pubkey forms, their various features and capabilities in real world cert schemes scenarios, and re MITM. There is a general encryption proponent mandate RFC, commensurate with Snowden events, the number escapes at this moment. Yes, more development of such a BCP as you mention regarding TLS fingerprint capabilities, and TLS extent forward in general, would be nice. That would then extend to many protocols in a default guide of reference way as to what is possible, including say NFS. It is difficult to say "MUST" or "SHOULD" or "MAY" regarding this fingerprinting business for NFS. But it may be reasonable that 5.5.2 be expanded to mention the two different fingerprint classes, the four modes, as reasonable desireables. And to then reference out to the OWASP links at the bottom of the RFC. Maybe then leverage that effort into a BCP with other application RFC groups regarding TLS. > For example, such a document ought to cover the tradeoffs among > the four validation options, and how a safe default be chosen. In general, > this looks like a good direction as trust anchors and trust anchor > management have always been a weak point in the web PKI > > The OWASP pages are a good start, but leave revocation for future work and > are weak on certificate replacement - in particular, the comment that the > "application would need to be updated regularly" appears to punt the > underlying app validation problem upward to the app store operators (e.g., > to defend against a rogue app that accesses the server via an MITM proxy > server), which doesn't mesh well with "An application which pins a > certificate or public key no longer needs to depend on others - such as DNS > or CAs". Some dependence on the app store operator may be unavoidable for > first-use. It is assumed, and guaranteed under public embarrassment of news media, that revocation will results in a physical regen and change of cert (triggering both cert DER and pubkey hard physical swapouts). Thus revocation, and the whole revocation "authority" repository CRL OCSP checks etc, is not at all coming into an issue in this fingerprint context, since they are entirely independant and fixed and local, and detect and resolve all such revocation swaps by very nature of fingerprint failure and fingerprint updates. The "application being updated regularly" is of course a nice option for such app shipping devs to do gratuitously for users. But has no bearing on users subsequent needed capability to pin whatever they want and feel is necessary independantly. If I were an NFS users in particular infrastructures and risks, I might want to pin the end server pubkey (or cert DER), or intermediate instances of the same (leaving server cert free to float) regardless of what my vertical or lateral silo, or other peer model, or CA, or rogue, says to accept. Is there a reasonable way to more strongly suggest implementation of those two fingerprint methods, and even some of the four modes, as options between server-client in the NFS TLS RFC? > There is a general encryption proponent mandate RFC... One might also try full text RFC search for "fingerprint" references in context of "TLS" (or the older "SSL"). The following incomplete list all in manner of spirit do generally give rise and encourage the offering and enablement of such security option sets in apps / protocols utilizing TLS... Recommendations for Secure Use of Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7525 Pervasive Monitoring Is an Attack https://tools.ietf.org/html/rfc7258 Privacy Considerations for Internet Protocols https://tools.ietf.org/html/rfc6973 Certificate Transparency https://tools.ietf.org/html/rfc6962 Strong Security Requirements for Internet Engineering Task Force Standard Protocols https://tools.ietf.org/html/rfc3365 Guidelines for Writing RFC Text on Security Considerations https://tools.ietf.org/html/rfc3552 IETF Policy on Wiretapping https://tools.ietf.org/html/rfc2804 IAB and IESG Statement on Cryptographic Technology and the Internet https://tools.ietf.org/html/rfc1984 "It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms." Privacy Requirements for IETF Protocols https://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-01 It is the consensus of the IETF that our protocols be designed to avoid privacy violations to the extent possible. Handling Pervasive Monitoring in the IETF (perpass) (WG) https://www.ietf.org/proceedings/88/perpass.html https://www.ietf.org/mailman/listinfo/perpass Not requiring app (NFS) spec implementations to have some options for some of the previously noted modes of fingerprint checking to help avoid some TLS MITM attacks, would seem to be in conflict with all above. > the premise that pinning by fingerprint is the > strongest security/authentication mechanism possible in many cases. It is certainly among the set of them that might be applied in various ways depending on the users security model. > In IETF documents we essentially universally leave the deployment's > selection of trust anchor(s) as a matter of local policy, and thus it is a > bit out of character for us to be recommending specific trust anchors or > classes of trust anchor. We provide robust security mechanisms and > describe how they can be safely used, but leave policy to others. Allow to better define below the context as being in supporting the presence of options for policies... > I'm not sure I understand your point here. You seem to be saying that > CA-driven revocation is orthogonal to key pinning, and thus that when a > revocation event occurs, the legitimate counterparty will generate a new > key (and fingerprint), with the resulting connection errors being detected > and used as a trigger to update local configuration. > But that doesn't make sense to me! If there's a revocation event and > presumed key compromise, then the attacker that got the key can continue to > use it against the deployment that pinned that key until the configuration > is changed. This seems to be ignoring the signal from the CA that > "something bad happened" and could lead to a long period of vulnerability. > It's far from clear to me that key pinning provides superior properties to > CA-based setups in the face of such revocation events. It is risky and then embarrassing to continue using a compromised private key. The compromise is the preceding and defining element, and rightly triggers a security rekey event. The rekey hash mismatch is, the and only required, signal when a users application is watching the fingerprint, if that is how the user configured their options. This is independant, and if so chosen "orthagonal", from any assertion or not as such by or to any CA signal crl scheme, that assertion being at that point, equally the same as pinning check, a separate function from the security compromise and restoration itself. Fingerprints, "CA signals", other checks, are independant cases, and can be combined in some users environments, provided they have options to do so. Further, many environments use CA only to avoid software CA nag warnings and have little knowledge or care for CRL systems, and many users have little knowledge or care to check them. People also often try to trot out this false argument of relying "CA signal" or revocation as some means to moot or demur the implementing of fingerprinting options in the app code, or to avoid configuring them. That is not the case. As to NFS... in this suggestion, nfsv4-rpc-tls in 5.2.2 needs to REQUIRE all conformant implementations to have fingerprint configuration OPTIONS for the user to use as they deem appropriate. This does NOT require users to use it, only that it be present as option in conformant implementations. If CA method of 5.2.1 is a REQUIRED security thing, then similarly, so can fingerprint security OPTION things of 5.2.2 be. If nfsv4-rpc-tls anywhere REQUIRES any things of any conformant implementations, then so can it require some fingerprint OPTIONS things. If nfsv4-rpc-tls 5.2.2 is already specifying a SHOULD-hint as to a "via"-form of SHA-256 being over the cert-DER form (with or without including reference to just what spec that is), it really must also fairly provide a SHOULD-hint as to the "via"-form of pubkey. That is probably simple enough, leaving the four modes and other option combinatrics up to the application teams, the possibility for such potentially hinted in note in section 7. External references are already possible by example of URI list in 9.3. Additionally, perhaps something in RFC5280 or similar could be noted or pointed to as RFC5280 was noted and or pointed to in 5.2.1. RFC's even have places available for further discussion and strong words encouragement, such as section 7. > fingerprint pinning is hardly ubiquitous in those protocols. Unfortunately that is largely because fingerprint pinning is a hardly understood black magic of additional TLS defence, in depth, hardly mentioned, referenced, documented, implemented, or educated on, etc. Most don't really understand MITM modes. And with all the noise droning on about CA, $fees, "validation" of corporate entites, advertising, who can blame them. This issue is a similarly common copout / chicken egg to the above CA CRL excuse for not creating fingerprint options. Beneficial ubiquity can be fostered by more rfc's, internet application docs, etc becoming a part of the set of same that begins and further integrates more mentions and supports for pinning options in their various works. It would suck to effort to add this TLS to NFS but not enjoy some fingerprint pinning options along with it, because, well, it was only a SHOULD, so your OS skipped them resulting in less than featureful. Oops. > It would perhaps be compatible to focus on the choice of trust anchor and > the possibility to pin intermediate certificates, but this again starts to > stray into areas that the IETF historically leaves as a matter of local > policy. Requiring pinning OPTIONS would enable this making of local policy choices among such options. No options, no choices. Users like having options and choices. Opportunistic Security: Some Protection Most of the Time https://tools.ietf.org/html/rfc7435.html