[hiprg] Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04)

[Robert Moskowitz <[e-mail]>]

 From Juho:

-------- Original Message --------

MAJOR QUESTIONS
---------------

3.2. Generating a HIT from an HI

It is said in 3.2. that the DEX HIT is generated from the HI by
left-truncating the HI into 96 bits. Except the problem that I have
discussed with Nie Pin before that the OGA 4-bit field is not defined in
the ORCHID specification, I am also confused by which 96 bits are
actually used.

According to 5.2.2. the HIT does not provide the HOST_ID key size and
the HOST_ID key size will be selected by the responder according to
DH_GROUP_LIST. My understanding is that the responder needs to have
multiple HOST_IDs and select the one matching the key size the initiator
  is requesting. Now, which one of the HOST_IDs will be used for the HIT
  generation? How can the initiator confirm that HOST_ID matches the HIT
  it is requesting. (if it cannot, this can result in a serious MITM,
because R1 is not CMAC'ed)


5.1. HIP Parameters

It is said in 5.2. that "For the BEX parameters ... HOST_ID, only the
ECC values are valid in DEX.". I went to see RFC5201-bis-02 to see
possible values for HOST_ID and the only ECC value for it was marked as
ECDSA. This seems plain wrong, because the HOST_ID used in DEX is
actually a static ECDH public/private keypair. Now it's possible to use
ECDSA value to represent ECDH curve, but even the ECC Curve values are
named confusingly as NIST-ECDSA-256 and NIST_ECDSA-384, even though they
are basically the same P-256 and P-384 curves used in Diffie-Hellman.

Just as a side note, why is there no value defined for the P-521 curve,
which is also commonly used and included in the RFC4754?


5.1.2. ENCRYPTED_KEY

I understand that this section is made as generic as possible, but to me
  it simply sounds very confusing. First of all it says that "some
encryption algorithms require an IV" and "for example the puzzle value,
I, can be used as an IV". Why not simply define the puzzle value I as an
  IV? I know it's good to give some freedom to the implementor, but
since  the ENCRYPTED_KEY is only used in I2 and R2 and both of them
define the puzzle value I explicitly as the IV, why confuse the
implementor here?

The same chapter also says that AES uses the PKCS5 padding scheme, which
  leads me to think that PKCS5 is somehow defined by AES. In fact it
seems  to be defined by the HIP DEX draft, and it should be explicitly
said so  to avoid confusion. The same sentence says "may specify padding
bytes  other than zero", but the padding in itself is not defined as
zero, so  that sentence sounds confusing. I know the padding is defined
as zero in  RFC5201 Section 5.2.1. TLV Format, but it still seems a bit
out of the context.

The last problem I have with this chapter is the note that "the length
of the cipher suite output may be smaller or larger than the length of
the value and nonce to be encrypted". This is combined with "extra
padding added to the set of parameters to satisfy the cipher block
alignment rules is not counted in HIP TLV length fields" and "If
necessary, additional Padding for 8-byte alignment is then added
according to the rules of the TLV Format in [RFC5201-bis]". Let's take a
completely hypothetical example:

1) I have a cipher that has an input and output block size of 16 bytes,
but in the last block it adds a checksum of 8 bytes
2) I have input data of 14 bytes, which means that the HIP TLV length
field is 14 bytes as well
3) I will pad the input data to the cipher block size of 16 and encrypt
it, this will result in 24 bytes of output data from the cipher
4) The total length of TLV is now 28 bytes and I need to pad it with
zeros to 32 bytes to satisfy the 8-byte alignment
5) Now I have a TLV with length field of 14 bytes, TLV padding of 4
bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher suite padding
6) Question is, how do I know how many bytes to feed to the decryptor,
when I cannot calculate the TLV padding size from the TLV length field?
I can always just use a hardcoded value (8) for the checksum length and
add it to the TLV length, but what if the checksum length varies? I
don't think HIP DEX implementation should know too much about the cipher
  internals.


FEEDBACK REQUESTED
------------------

1.1. The HIP Diet EXchange (DEX)

It is said that the initiator should wait for some delta time after it
received the R2 packet until it can start sending the actual data
because of the aggressive retransmission. I think it would be useful to
explain this a bit more, for example what would happen if the data is
transmitted too early or how it can be detected that the receiver has
finished handling I2 packets.


4.1.1. HIP Puzzle Mechanism

It's a good thing that the puzzle mechanism is defined as pretty generic
  and free for the implementor to decide. However, personally I would
make  the reference to Appendix A much stronger. The algorithm used in
Appendix A uses both IP address of the initiator and IP address of the
responder in generating the I. If the IP addresses (or some other lower
  layer addresses) are not used in the generation of I, it results in a
  situation where an attacker can solve the puzzle once and start a DDoS
  attack of I2 packets that can last 3*lifetime of the puzzle if
implemented as suggested in the draft.

I think it would be safer and much more clear to note that not using the
  method presented in Appendix A to generate the puzzle might have some
  serious security considerations. I agree it should be free for the
implementor to decide what kind of puzzle to use, but he should at least
be aware of the consequences.


5.2. HIP Packets

Why is DH_GROUP_LIST sent in R1 at all? The draft says it can be
manipulated by an attacker and therefore is sent in R2 again, but
sending it in R1 seens to be completely redundant. Another question is
why is the DH_GROUP_LIST repeated so many times to begin with? It might
make sense in BEX where the key exchange is ephemeral and the attacker
could select a very weak key length and therefore be able to calculate
the private key. But in DEX the initiator should only support safe
Diffie-Hellman keys, since they work as its HOST_ID as well. If the
server sends a smaller key length than requested, the attack is very
easy to detect anyway.

Also what I already mentioned earlier, I understand the HOST_ID is used
as the public key for encrypting the secret-x. How does HIP DEX defend
against an attacker that modifies the HOST_ID in the R1 packet, since R1
  packet is not protected by the CMAC? Does HIP DEX assume that client
has  received the full HIs of all key lengths from some other secure
channel and not just the HIT? If it does, I think it should be said more
clearly.


EDITORIAL CORRECTIONS
---------------------

Section 1:
"A simple trunctation function for HIT generation."

Suggestion:
"A simple truncation function for HIT generation."

Section 1.1:
"As such the Intiator should take care to NOT send the first data packet
until some delta time after it received the R2 packet."

Suggestion:
"As such the Initiator should take care to NOT send the first data
packet until some delta time after it received the R2 packet."

Section 3:
"The HIT DEX hit is not generated via a cryptographic hash."

Suggestion:
"The HIP DEX HIT is not generated via a cryptographic hash."

Section 4.1:
"The term "key" refers to the Host Identity public key, "secret" refers
to a random value encrypted by a public key, and "sig" represents a
signature using such a key."

Suggestion:
"The term "PK" refers to the Host Identity public key and "secret"
refers to a random value encrypted by a public key."

Section 5.1:
"For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, only
  the ECC values are valid in DEX."

Suggestion:
"For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID,
only the ECC values are valid in DEX."

Appendix B. seems to be missing, I expect this to be a known issue. It
would be nice to know a bit more about what is to be included there though.