[Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 04 March 2020 18:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 395A43A143D; Wed, 4 Mar 2020 10:28:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, gonzalo.camarillo@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <158334652621.29471.12249385526499303915@ietfa.amsl.com>
Date: Wed, 04 Mar 2020 10:28:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/xluJQsma62OBn2d4QfRwvq4QRd4>
Subject: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 18:28:47 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-hip-dex-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (initial ballot now that this draft is deferred) ** Section 1.2. Thanks for the scoping provided by this applicability statement. Given the reduced security that DEX will provide, IMO it needs a bit more precision (and caution). OLD HIP DEX MUST only be used in communicating with such constrained devices (e.g., class 0 and 1 devices as defined in section 3 in [RFC7228]). NEW HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained device as defined in Section 3 of [RFC7228]. HIP DEX MUST NOT be used if both peers are class 2 constrained devices or have greater capability. ** Section 3.2.1, Per “Since collision-resistance is not possible with the tools at hand, any reasonable function (e.g. FOLD) that takes the full value of the HI into generating the HIT can be used, provided that collision detection is part of the HIP-DEX deployment design. This is achieved here through either an ACL or some other lookup process that externally binds the HIT and HI.”, when exactly should this ACL lookup occur? Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be. ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the HIP Group ID sub-registry? If so, Curve25519 and Curve448 don’t appear to be in the https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5? Should they be registered? ** Section 6.3. Per “Some payload protection mechanisms have their own Key Derivation Function, and if so this mechanism SHOULD be used.”, if the payload protection mechanisms have their own KDF, how would their security properties be trusted if their KDF is NOT used? Why is this SHOULD not a MUST? ** Section 6.3. The input to CKDR-Extract seems underspecified: -- Per the definition of IKM, when should these different inputs be used (at least two appear to be specified)? References to Kij are made in this section and in other parts of the document, but they aren’t input for CKDR-Extract()? -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info” in CKDR-Extract(), what encoding should be used to convert that into an octet string? Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116? ** Section 9. Please add language to the effect that “production deployments of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the language already stated in Section 5.2.2 on the topic). ** Section 9.2. This mandatory guidance to validate public keys is helpful. Please provide guidance in an explicit step in the appropriate packet processing section (i.e., in Section 6.*) on when this should be done. Two “discuss discuss”-es with the caveat that I didn’t follow the WG discussions. ** The following seems to indicate we don’t have everything we need to publish a standards track document: -- Section 6. “It should be noted that many of the packet processing rules are denoted here with "SHOULD" but may be updated to "MUST" when further implementation experience provides better guidance.” -- Section 9. “o The puzzle mechanism using CMAC explained in Section 4.1.1 may need further study regarding the level of difficulty in order to establish best practices with current generation of constrained devices.” If there isn’t sufficient implementation experience, why isn’t this document experimental? What is the plan for getting better guidance? Is there a risk in not having this clarity? ** Section 9.1. Thanks for this section. However, I’m not convinced that SECP160R1 is needed. DEX is already selectively profiling RFC7401 (i.e., its already choosing to exclude certain things) and there are “no production” implementation of DEX. What is the rationale for keeping it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 3.0. Per “Thus, it is not expected that these parameters are carried in every packet, but other methods are used to map the data packets to the corresponding His”, what are these other methods? ** Section 3.1. Per “There are two advantages of using a hashed encoding over the actual variable-sized public key in protocols.”, perhaps as a reminder is in order that in this document the HIT isn’t a hashed encoding but a compressed. ** Section 4.1. Per “Note that in some cases it may be possible to replace this trigger packet by some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet.”, how does this additional trigger occur? ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's supported DH Groups (e.g., by using a default group) must be specified.”, where/how would it be specified? ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a value larger than the worst-case anticipated round-trip time (RTT ).”, how is the worst case RTT computed? ** Section 5.3.2. Per “Responder sets the source HIT in the R2 packet based on the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the source HIT in the _R1_ packet …”? ** Section 5.3.2. Per “Based on the deviating DH group ID in the HOST_ID parameter, the Initiator then SHOULD abort …”, why not MUST abort? ** Section 6.8. Step 5. Per “5. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy.”, this guidance seems underspecified. Could the text at least provide a recommendation of aborting and logging? ** Section 9. Per “The strength of the keys for the Pair-wise Key SA is based on the quality of the random keying material. As either peer may be a sensor or an actuator device, there is a natural concern about the quality of its random number generator.”, this is helpful caution. What guidance can be given to ameliorate the concern? ** Editorial -- Section 1.2. The sentence “Also, it is often the case that HIP DEX …” is repeated twice. -- Section 4.1. s/the the/the/ -- Section 6.3. Typo. s/The HIP DEX KEYMAT process is based on the is the/ The HIP DEX KEYMAT process is based on the/ -- Section 9.2. Editorial. Per “With the curves specified here, there is a straightforward key extraction attack, which is a very serious problem the use of static keys in HIP-DEX”, there appears to be some missing words – perhaps “… with the use of static keys by HIP-DEX”.
- [Hipsec] Roman Danyliw's Discuss on draft-ietf-hi… Roman Danyliw via Datatracker