Re: [Hipsec] Last Call comments on draft-ietf-hip-dex-11

[Robert Moskowitz <[e-mail]>]

Eric,

I thank you for your review.  There are some really good insights within 
it.  I will provide my comments here on how I plan to handle them.

On 11/3/19 3:31 PM, Eric Rescorla wrote:
> Sorry for the standalone message. I don't seem to be subscribed to
> ietf-announce, so can't reply.
>
> I do not believe that this meets the security standards that we
> currently use for designing protocols at IETF. As a general matterE,
> this document seems to cut a large number of corners in the service of
> some unspecified "overhead" goal, yet it never describes what the
> targets are (though presumably this is somehow about computation and
> bandwidth), and so it is not possible to evaluate the document against
> them. At present, I am unable to say whether it's necessary to do a
> new document at all.
>
> The rest of this message details specific deficiencies of this
> protocol which should be addressed. Aside from these, it's fairly
> unfortunate to see a design for a protocol that uses such an unusual
> cryptographic core for no obvious reason. This makes it very hard to
> analyze. It would be far better to use SIGMA or some other
> well-analyzed construction.
>
>
> LACK OF PFS
> The most serious concern here is the lack of Forward Secrecy. This is
> a straightforward static-static DH exchange, but it is not possible to
> provide FS in that scenario, as S 1 acknowledges. I have two concerns
> here: First, FS is simply table stakes in a modern AKE protocol, so I
> don't think we should be publishing a document that doesn't have it
> on the standards track.
>
> Second, even if we were to concede that FS might be optional, the
> design choices here don't make any sense. There are two major costs to
> DH: the cost of doing the DH computations and the bandwidth of sending
> the keys. However, given the wide range of the curves permitted here
> (X25519 to P521), even a full triple-DH protocol will be far more
> efficient on both counts than the existing protocol with P521 (indeed,
> it's probably as or more efficient than the existing protocol with
> P256).
>
> Proposed action: This protocol needs to be revised to have forward
> security.

dex-12.txt will have an applicability statement.  You will see text 
there that cover work on an 8501 chip with the timings and thus why the 
design.

> HIT GENERATION
> Previous versions of HIP generated HITs from HIs by computing a secure
> hash on the HI. This document converts them by a novel folding
> procedure. There is no good reason to believe that it is hard to
> generate a key that has a given HIT (indeed there are good reasons to
> believe it *is* reasonably efficient for non-EC algorithms). The
> document sort-of-acknowledges this in Section 9:
>
>    o  The HIP DEX HIT generation may present new attack opportunities.
>       Hence, HIP DEX HITs MUST NOT be used as the only means to identify
>       a peer in an ACL.  Instead, the use of the peer's HI is
>       recommended as explained in Section 3.
>
> However, it's not clear it's sufficient, because nothing strongly
> binds the HI (as opposed to the HIT) to the handshake, so attacks
> may still be possible if the HI is used (via UKS-like attacks). In
> any case, this is a regression from HIPv2.
>
> It's not even clear why this change was made: given that you
> have CMAC, you should be able to use this to produce a hash of
> the key.
>
> Proposed action: generate HITs from HIs securely.

First point, the HIs are contained in the R1 and I2 packets.  Thus they 
are bound to the handshake.  The HIT is an index to the ACL (or other 
lookup mechanism) and duplicates are not allowed.  So it is a 'first 
come, first allowed' process for HIT to HI mappings. We have always 
recognized the risk of duplicates, even with the probability being very 
low with a 96 bit truncation of the hash in HIP-BEX.

That said, I considered your recommendation to use CMAC rather than my 
novel FOLD operation that I got from another security source. From my 
original notes, I remembered that the challenge in using CMAC for HIT 
generation is what to use for the key.  Should I just use ZERO or some 
published random value.  So I asked NIST and here is the official response:

"We cannot endorse either choice.  The function you describe--CMAC with 
a published key--is not an approved cryptographic hash function.  
Indeed, It is straightforward to demonstrate that this function is not 
collision-resistant for any choice of the key."

So the only reason to switch to CMAC is to satisfy some thought that it 
would less likely cause a problem than the FOLD function. Either way 
there is need for explaining the need to defend against duplicate HITs, 
both 'natural' and forced.  And CMAC has a higher computing cost than FOLD.

Right now I feel that I should leave it as is and that the text is 
adequate to describe the risk.  If you feel I need more warnings, I will 
write up text for the security section.  If you feel that CMAC should be 
used just because, we can discuss it further.

> WEAK EC GROUPS
> This document specifies the use of SECP160R1. This is not an acceptably
> secure group.
>
> Proposed action: REmove support for SECP160R1.

SECP160R1 is carried over from RFC 7401.  At the time, there were 
participants that wanted something for those really limited CPUs (like 
the 8501).

Now we have EC25519 and it can be argued that its performance and 
transmitted key size (for constrained networks) meets the needs for 
those that wanted SECP160R1.  My concern is I have no data on the CPU 
cost on a 8501 for SECP160R1 to make a valid comparison to EC25519.

Further the adding of EC25519 does not replace SECP160R1 in HIP-BEX (RFC 
7401), so at best, all I could do is not include it in HIP-DEX, it still 
would be valid for HIP-BEX.

For now I am leaving SECP160R1 in unless I get feedback that we can 
deprecate it for EC25519.  Note that a separate draft, 
draft-moskowitz-hip-new-crypto, is adding EDDSA25519 for HIP-BEX and 
there we can deprecate SECP160R1.


> FAILURE TO VALIDATE PUBLIC KEYS
> This document does not require that implementations validate
> the remote public key. With the NIST curves specified here,
> this leads to straightforward key extraction attacks, which
> is a very serious problem when you have a static key.
>
> Proposed action: Require point validation. The TLS 1.3 has
> text you can borrow.

I am assuming you mean sec 4.2.8.2 of RFC8446?

I am shocked that we have to tell implementers to test that the EC PK is 
a valid point.  Not.

I will use this text as the basis for an addition subsection in Security 
Considerations.

> AEAD
> This document makes use of non-AEAD symmetric algorithms. This has been
> found to be hazardous in practice.
>
> Proposed action: use only AEAD algorithms.

All HIP payloads that occur after there are agreed keys, are 
authenticated (MACed).  Few payloads have encrypted parameters. Further 
the way parameters are organized within the payload it is possible that 
the encrypted parameters would not be adjacent, making further 
complications.   It does not make sense to switch to an AEAD with this 
design.  Plus an AEAD adds processing overhead.  IF NIST had completed 
the lightweight crypto competition at design time, then AEAD may have 
been given closer study.

> REPLAY ATTACK ON AKE
> The only entropy provided to the AKE is the puzzle, which means
> that it's possible for an attacker to replay the responder's
> messages, leaving the initiator believing that he has created
> a connection when in fact he has not. The attacker will not
> be able to send data messages because the initiator contributes
> data to the eventual keys, but we generally try to avoid this
> property.
>
> More importantly, this is unnecessary, and can be resolved
> by changing the odd "encrypt half the key" mechanism used here
> with a conventional nonce structure in which each side sends
> a random value and then you HKDF it with the DH shared secret.
> This would have the effect of removing the replay attack
> and be easier to analyze.
>
> Proposed action: restructure the AKE to mix nonces + DH
> into the key schedule.

This is a good suggestion.  I am still studying it for the best way to 
implement it.  I do expect to have something done for a dex-13.txt draft.


>
> -Ekr
>

Robert Moskowitz