Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20
Valery Smyslov <valery@smyslov.net> Fri, 27 August 2021 16:14 UTC
Return-Path: <valery@smyslov.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBF3A1412; Fri, 27 Aug 2021 09:14:50 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 n1uIMlIi-7mT; Fri, 27 Aug 2021 09:14:43 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156903A140F; Fri, 27 Aug 2021 09:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=oTGB8ROnhmf2dc6rHqn0QBKZnqdw6fE4JiAHMQrovmQ=; b=mJz753VN3dfe6qRd8oJRNHNXCr +Y38ONE/oPdBEE/CDjNX5r6WrDl3ygqv7E181lXL1JaBkbpkBFqnCy9qRj+pqs1LSMykHHispHCNU i7ulcSCdZ51zkisUfHGHrT194NFBLEssJvz/UMXEzWoK0uPNdm89o6lurSEOqE5B14KEw8SBi/KRf 4438EVhrlj+0S04BM8dyC2P11nYb8xzA/M03M9bPcbrXlGt/sJLICBJoWxrJA8e+aELmYJ34uzhMv iL5apKnlYwvxTFEjVVEvUfiexCmjqVPfYMwrQuEIDGcXZ/CIFvS0MIaPsQDmV+aYB6s3BXWSeGmIC OdZgh8/g==;
Received: from [93.188.44.204] (port=62899 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <valery@smyslov.net>) id 1mJeV3-0007rS-Kj; Fri, 27 Aug 2021 12:14:38 -0400
From: Valery Smyslov <valery@smyslov.net>
To: 'Kent Watsen' <kent+ietf@watsen.net>
Cc: secdir@ietf.org, draft-ietf-netconf-crypto-types.all@ietf.org, netconf@ietf.org
References: <162982978380.3381.17549750696257276827@ietfa.amsl.com> <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com>
In-Reply-To: <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com>
Date: Fri, 27 Aug 2021 19:14:30 +0300
Message-ID: <017c01d79b5e$a00a0000$e01e0000$@smyslov.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01D79B77.C55A4540"
X-Mailer: Microsoft Outlook 14.0
Content-Language: ru
Thread-Index: AQGndKy5sGszK4BuDx47nymU5VnBUwHC5W7jq9m0WHA=
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ZOFiqNOvdB6ILLoGaBCtPOltkuw>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Aug 2021 16:14:50 -0000
Hi Kent, thank you for addressing my comments. A bit more inline. [removing “last-call” alias] Hello Valery. Thank you for your SecDir review, it is very much appreciated and never too late! More comments below. Thanks, Kent On Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker <noreply@ietf.org> wrote: Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. When I was re-assigned to review this draft the indicated deadline was already missed by 8 months, so I don't know how relevant the review is. I reviewed the latest -20 version of the draft instead of -18, that was requested. Perfect. The draft defines common YANG data types and groupings useful for cryptography. I din't try to check the YANG module itself. Issues: Shouldn't a Privacy Considerations section be added to the draft? The draft defines quite a lot of privacy-sensitive information (like certificates) with no restriction on read access (as far as I understand). Both the "trust-anchor-cert-grouping” and “end-entity-cert-grouping” groupings have "nacm:default-deny-write” that, to your point, does not restrict reads. That said, only management protocols having mutual authentication (e.g., SSH and/or TLS based transport) can access the data. Is your concern that the certificate’s content would be visible to the administrators? Is your comment on end-entity certificates (containing personally-identifying information), more than trust-anchor-certificates? Yes, it’s mostly on end-entity certificates, however there may be quite a lot of interesting private information besides certificates. If this information is only visible to the administrators and the used management protocols must have mutual authentication, then it’s probably not a big deal. I would have still added a sentence about privacy of the stored data (i.e. that persons, that are allowed to access this data are able to learn quite a lot of private information from it). I don’t insist though, it’s up to you. Section 3.5. While I understand and support the idea, expressed in this section, I think that the way it is expressed makes it difficult to follow in practice. In general, it's not always obvious how to estimate the "strength" of the underlying secure transport. For this reason it's not clear for me how it is supposed to "compare" the "strength" of the transport with the "strength" of the keys being transported. I saw language like this once in a DoD setting. I agree that it is difficult to implement in practice. I used “SHOULD” (not MUST) to buy some leeway for implementations to be compliant. Makes sense? My understanding of using RFC2119 language is that SHOULD is very close to MUST, but allows some exceptions. So, I still think that you put a responsibility to make security-related decisions on implementers, who often are not experts in this area. FWIW, my YANG-driven server is able to remember what key the client used for authentication (e.g., RSA 2048) and register a callback to test that no greater keys (e.g., 3072 or 4096) are configured by that client. Additional What if the other key configured for the client is X25519? Which is stronger? logic would be needed to prevent a low-strength client from *reading* a high-strength key configured by another client…though the issue can be alternatively resolved by configuring the TLS-stack to prevent low-strength algorithms. That was my point. I think that it’s better to require (by SHOULD) that only those ciphersuites that were “vetted” by IETF (i.e. got “Recommended” status) be used. This will make implementers’ life easier. In addition, the requirement, that "Implementations SHOULD fail the write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. IDK about this. Again, I saw this constraint once in a DoD setting. My (another) point was that there is generally no point to increase security strength beyond some level. Currently it is believed that 128 bit of symmetric key is infeasible to break (provided the algorithm is not broken itself), If you are lucky have full-sized Post Quantum computer, it’ll be 256 bits. It’s enough to transfer symmetric keys with say 1024 bits of entropy (FWIW). So the requirement that the strength of transport must be always greater than the strength of transported key seems not a good requirement to me. Instead require that the strength of transport be sufficient to make infeasible for an attacker to break it. I think that the better approach would be to advise using strong ciphersuites for transport protocols defined in corresponding RFCs. For example, for TLS 1.3 there are ciphersuites marked as "recommended", that were evaluated by IETF crypto community. I added this sentence: Implementations SHOULD configure allowed transport algorithms to include only those meeting local policy (e.g., listed as "recommended" by the IETF). Good? Perfect. Regards, Valery. Section 3.6: For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. Not only IV for CBC should be unique, it should be unpredictable (random or pseudo-random). I also think that lowercase "should" here must be uppercase, or even MUST. Replaced “unique” with “unpredictable” Replaced “should” with MUST. Typos, nits: Section 3.6: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD be used. s/SHOULD/SHOULD NOT Egads - fixed! For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. s/EBC/ECB s/it// I believe "okay' is a bit of slang, isn't it? Fixed, now reads: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD NOT be used. For instance, AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is permissible since an unpredictable initialization vector (IV) MUST be used for each use.</t> Section 3.8: Since the module in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings. s/define/defines Fixed! Kent, as author
- [secdir] Secdir last call review of draft-ietf-ne… Valery Smyslov via Datatracker
- Re: [secdir] [Last-Call] Secdir last call review … Kent Watsen
- Re: [secdir] [Last-Call] Secdir last call review … Valery Smyslov
- Re: [secdir] [Last-Call] Secdir last call review … Valery Smyslov
- Re: [secdir] [Last-Call] Secdir last call review … Kent Watsen
- Re: [secdir] [Last-Call] Secdir last call review … Valery Smyslov
- Re: [secdir] [Last-Call] Secdir last call review … Kent Watsen
- Re: [secdir] [Last-Call] Secdir last call review … Valery Smyslov
- Re: [secdir] [Last-Call] Secdir last call review … Kent Watsen
- Re: [secdir] [Last-Call] Secdir last call review … Valery Smyslov