Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)

[Robert Moskowitz <[e-mail]>]

Ben,

thank you for the serious, in-depth, review.  It will take a bit to work 
through your comments.

vis-a-vis, LAKE.

It would be seriously challenging, and interesting, to review the 
long-standing work on HIP-DEX with the new work on LAKE.  If so, I would 
end up throwing in to remove all AES constructs for KECCAK alternatives 
with small sponges.  Maybe.  This would be a serious piece of work.  But 
I will think on it.

And I AM doing KECCAK in the hip-new-crypto draft.  But it is not an 
alternative to DEX.

On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk 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:
> ----------------------------------------------------------------------
>
> This is a placeholder discuss, intended to illustrate several key
> omissions from the current document and as an indication that it is not
> yet ready for full IESG Evaluation.  In that vein, I will defer the
> evaluation shortly, to attempt to short-circuit the current round of
> evaluation while the draft improves.  In particular, this is not
> intended to be a complete review of the document.
>
> The FOLD scheme for compressing full host identities into ORCHIDs/HITs
> is pretty problematic.  The current text acknowledges that collisions
> are possible and attempts to justify the scheme by pointing out that no
> collision-free scheme is possible absent a cryptographic hash, which is
> an appeal to authority ("we can't use a cryptographic hash on
> constrained systems") that does not attempt to answer the question of
> whether it is actually reasonable to use a mechanism that allows
> collisions for this purpose (vs. just not being able to do anything).
> Additionally, there is not any discussion of second-preimage resistance,
> which is the more important property here, in terms of an attacker being
> able to construct a collision with an existing HIT of an honest node.
>
> In a related vein, Section 3.2.1 claims that the above concerns can be
> remediated by deployment of a collision detection scheme, "achieved here
> through either an ACL or some other lookup process".  This process is
> vital to the security of the system as a whole, and it would be
> irresponsible to publish this document without a precise specification
> of what properties are needed in order to perform this process, as well
> as a worked example that can be used absent other considerations.
>
> Given that the applicability statement ("in communicating with such
> constrained devices") implies that there is intent to have full-featured
> nodes that implement both HIP DEX and HIP BEX, I think we need
> significantly more discussion of how such nodes avoid using DEX in
> situations where it was not appropriate.  That is, how is it known that
> the peer should be using DEX vs. BEX?  Yes, the HIT includes an
> indication of whether the identity is for use with DEX vs. BEX, but that
> does not seem like quite the relevant property.  Do we envision
> scenarios where a node is positioned somewhat like a gateway, using DEX
> on one interface and BEX to the broader internet?
>
> Using AES-CTR with the long-term static-static master key requires
> careful tracking of counter (sequence) number to nonvolatile storage.  I
> did not see discussion of the security consequences of inadvertent
> counter reuse.
>
> I appreciate the design to limit use of the long-term static-static
> master key to essentially just key-wrap operations, but this seems to
> require the presence of a CSPRNG in order to obtain secure session keys.
> Expecting a strong CSPRNG on a node so constrained that DEX is necessary
> seems to be a questionable assumption, and I see no discussion of the
> need for a good RNG.  (Relying on the full-featured peer to contribute
> good entropy to the key derivation is not an option, since DEX is
> allowed to be used between two nodes that are both constrained.)
>
> The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF)
> construction, analogous to HKDF (RFC 5869).  However, the paper
> motivating 5869's design choices does not seem to justify the usage of
> CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with
> AES) is only a PRP.  Absent some detailed justification or prior art it
> does not seem prudent to use such a novel construction for
> security-critical functionality.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Some additional comments (also incomplete), since they were already written.
> It would be reasonable to ignore for now any that don't make sense or
> are on parts of the text likely to change as a result of the higher-level discussion.
>
> Abstract
>
> My preference is to just use "forward secrecy" rather than "perfect
> forward secrecy", as perfection is hard to attain.
>
> Section 1.1
>
>     HIP DEX operationally is very similar to HIP BEX.  Moreover, the
>     employed model is also fairly equivalent to 802.11-2007
>     [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
>     handled in a single exchange.
>
> 802.11 security does not exactly have a shiny track record...
>
>     HIP DEX does not have the option to encrypt the Host Identity of the
>     Initiator in the I2 packet.  The Responder's Host Identity also is
>     not protected.  Thus, contrary to HIPv2, HIP DEX does not provide for
>     end-point anonymity and any signaling (i.e., HOST_ID parameter
>     contained with an ENCRYPTED parameter) that indicates such anonymity
>     should be ignored.
>
> What would you do if you didn't ignore such signalling?  Drop the
> connection as being with a misbehaving peer?
>
>     As in [RFC7401], data packets start to flow after the R2 packet.  The
>     I2 and R2 packets may carry a data payload in the future.  The
>     details of this may be defined later.
>
> I'm not sure what value is added by mentioning the possibility of data
> payload in I2/R2.
>
>     An existing HIP association can be updated with the update mechanism
>     defined in [RFC7401].  Likewise, the association can be torn down
>     with the defined closing mechanism for HIPv2 if it is no longer
>     needed.  In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
>     the original HIPv2 specification.
>
> I think the intent here is more along the lines of "HIP DEX does so even
> in the absence of the HIP_SIGNATURE that is used in standard HIPv2".
> (I also note that there's some subtle semantic mismatch between DEX as
> "diet exchange" and its used to indicate continuing lack of security
> functionality throughout the extent of the association, after the
> exchange is completed.)
>
>     Finally, HIP DEX is designed as an end-to-end authentication and key
>     establishment protocol.  As such, it can be used in combination with
>
> Don't we have a LAKE WG now?  How does DEX compare to what they are
> working on?
>
> Section 1.2
>
> In lieu of detailed comments, allow me to propose a rewrite of the whole
> section:
>
> % HIP DEX achieves its lightweight nature in large part due to the
> % intentional removal of Forward Secrecy (FS) from the key exchange.  Current
> % mechanisms to achieve FS use an authenticated ephemeral Diffie-Hellman
> % exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage on devices where
> % even the most lightweight ECDH exchange is prohibitively expensive for
> % recurring (ephemeral) use.  For example, experience with the 8-bit
> % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 keypair
> % generation exceeds 10 seconds and consumes significant energy (i.e.,
> % battery resources).  Even the ECDH multiplication for the HIP DEX
> % static-static key exchange takes 8-9 seconds, again with measurable
> % energy consumption.  This resource consumption is tolerable as a
> % one-time event during provisioning, but would render the protocol
> % unsuitable for use on these devices if it was required to be a
> % recurring part of the protocol.  For devices constrained in this
> % manner, a FS-enabled protocol will likely provide little gain.  The
> % resulting "FS" key, likely produced during device provisioning, would
> % typically end up being used for the remainder of the device's
> % lifetime.  With such a usage pattern, the inherent benefit of
> % ephemeral keys is not realized.  The security properties of such usage
> % are very similar to those of using a statically provisioned symmetric
> % pre-shared key, in that there remains a single PSK in static storage
> % that is susceptible to exfiltration/compromise, and compromise of that
> % key in effect compromises the entire protocol for that node.  HIP DEX
> % achieves marginally better security properties by computing the
> % effective long-term PSK from a DH exchange, so that the provisioning
> % service is not required to be part of the risk surface due to also
> % possessing the PSK.
> %
> % Due to the substantially reduced security guarantees of HIP DEX
> % compared to HIP BEX, HIP DEX MUST only be used when at least one of
> % the two endpoints is a class 0 or 1 constrained device defined in
> % Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both endpoints
> % are class 2 devices or unconstrained.
>
> Section 2.2
>
>     Ltrunc (M(x), K)   denotes the lowest order K bits of the result of
>        the MAC function M on the input x.
>
> I'm not sure I'm going to interpret the "lowest order K bits" the same
> way that everyone else will.  I think "leftmost" or "first" are more
> common terms for describing this sort of truncation.
>
> Section 2.3
>
>     CMAC:  The Cipher-based Message Authentication Code with the 128-bit
>        Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493].
>
> I would suggest just using CMAC as the acronym and not trying to
> overload it to also be AES-specific.
>
>     HIT Suite:  A HIT Suite groups all algorithms that are required to
>        generate and use an HI and its HIT.  In particular, these
>        algorithms are: 1) ECDH and 2) FOLD.
>
> For DEX.  For normal HIPv2 we wouldn't touch FOLD with a long pole.
>
>     HI (Host Identity):  The static ECDH public key that represents the
>        identity of the host.  In HIP DEX, a host proves ownership of the
>        private key belonging to its HI by creating a HIP_MAC with the
>        derived ECDH key (see Section 3).
>
> This may sound pedantic, but this doesn't actually prove ownership of
> the private key.  Someone who knows the private key of the other party
> and the public key of the host in question would be able to produce the
> same MAC from the corresponding derived ECDH key.  I think the most we
> can say here is that a host authenticates itself as that host identity
> [with that HIP_MAC].  There's the corresponding trust of the recipient
> that its own private key remains secure and thus that no party other
> than itself or the peer identity could have generated that message.
>
>     Initiator:  The host that initiates the HIP DEX handshake.  This role
>        is typically forgotten once the handshake is completed.
>
> "typically"?  Perhaps it's best to say that the role is not used or
> needed after the handshake is completed.
>
>     KEYMAT:  Keying material.  That is, the bit string(s) used as
>        cryptographic keys.
>
> I'm surprised we need an abbreviation for this.
>
>     Length of the Responder's HIT Hash Algorithm (RHASH_len):  The
>        natural output length of RHASH in bits.
>
> [this doesn't really fit the pattern of "definition"s]
>
>     Responder:  The host that responds to the Initiator in the HIP DEX
>        handshake.  This role is typically forgotten once the handshake is
>        completed.
>
> [same thing re "typically"]
>
> Section 3
>
>     HIP DEX implementations MUST support the Elliptic Curve Diffie-
>     Hellman (ECDH) [RFC6090] key exchange for generating the HI as
>     defined in Section 5.2.3.  No additional algorithms are supported at
>     this time.
>
> It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090
> discusses the general class of things but is not a specific key exchange
> algorithm (e.g., curve).
> I'd also consider s/supported/defined/.
>
>     Due to the latter property, an attacker may be able to find a
>     collision with a HIT that is in use.  Hence, policy decisions such as
>     access control MUST NOT be based solely on the HIT.  Instead, the HI
>     of a host SHOULD be considered.
>
> I don't think this is correct or a strong enough statement.  In
> particular, I don't think access control should be based on the HIT at
> all, so strike "solely".  Also, the "SHOULD" seems too week.  I can
> understand that "MUST use the HI" could be overly constraining, but
> "access control decisions MUST be made on the actual identity of the
> host, e.g., the full HI" should allow for sufficient flexibility.
>
>     Carrying HIs and HITs in the header of user data packets would
>     increase the overhead of packets.  Thus, it is not expected that
>
> s/and/or/?
>
>     association.  When other user data packet formats are used, the
>     corresponding extensions need to define a replacement for the
>     ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
>     but this procedure is outside the scope of this document.
>
> Why is ESP_TRANSFORM the most important parameter here, when we talk
> about mapping a packet to the HIP association?  I thought ESP_TRANSFORM
> was literally about the encryption mechanics, not metadata around it.
>
> Section 3.2
>
> ORCHID claims to provide statistical uniqueness and routability at some
> overlay layer, neither of which this FOLD procedure provides, due to
> easily-generatable second preimages.
>
> Section 3.2.1
>
>     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
>
> This is not an argument that this is a reasonable thing to do; it's
> merely an argument that it's a thing that can be done that has the same
> claimed properties as the only type of thing that could be done.  It
> might be a bad idea to do the only type of thing that can be done, and
> you have not convinced me otherwise.  (See also the distinction between
> collision-resistance and second-preimage-resistance alluded to in my
> comment on the previous section.)
>
>     here through either an ACL or some other lookup process that
>     externally binds the HIT and HI.
>
> Without at least one well-specified mechanism for actually doing this
> and clear documentation of what precise properties such a mechanism
> needs to provide, I think it's irresponsible to publish this document.
>
> Section 4.1
>
>     By definition, the system initiating a HIP Diet EXchange is the
>     Initiator, and the peer is the Responder.  This distinction is
>     typically forgotten once the handshake completes, and either party
>     can become the Initiator in future communications.
>
> ["typically" again]
>
>     Diffie-Hellman Group IDs supported by the Initiator.  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.  In such cases, another mechanism to
>     convey the Initiator's supported DH Groups (e.g., by using a default
>     group) must be specified.
>
> This seems under-specified for a proposed standard and is probably
> better off omitted entirely.
>
>     The second packet, R1, starts the actual authenticated Diffie-Hellman
>     key exchange.  It contains a puzzle - a cryptographic challenge that
>     the Initiator must solve before continuing the exchange.  The level
>     of difficulty of the puzzle can be adjusted based on level of trust
>     with the Initiator, current load, or other factors.  In addition, the
>
> The Initiator is unauthenticated at this point, so "level of trust"
> seems to not really be defined...
>
> Section 4.1.1
>
> If an unconstrained (DoSing) attacker is competing with a constrained
> honest initiator to solve puzzles during an attack, it seems like the
> honest initiator is going to lose out pretty badly.
>
> Section 4.1.4
>
> There are security considerations for serializing the HIP state to
> nonvolatile storage!
>
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit