Re: Fwd: Last Call comments on draft-ietf-hip-dex-11

This is a multi-part message in MIME format.
--===============8653827995512250906==
Content-Type: multipart/alternative;
 boundary="------------6ADA6DDF40A4D73B7A2B989A"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------6ADA6DDF40A4D73B7A2B989A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Right now I will only reply to the AEAD comment.

I believe this is directed to the HIP_CIPHER parameter and its use in a 
number of HIP parameter objects.  The ECHO may be encrypted with it and 
in DEX we add the PSK.

Since all HIP packets that contain these fields are MACed with HIP_MAC, 
it is deemed that the TLVs within the HIP packet do not need to use an 
AEAD.  In fact RFC already specifies:

         RESERVED           0
         NULL-ENCRYPT       1     ([RFC2410])
         AES-128-CBC        2     ([RFC3602])
         RESERVED           3     (unused value)
         AES-256-CBC        4     ([RFC3602])

This is covered in 7401 and an implementer of DEX will know that the 
whole packet is MACed.

Other responses to come separately.



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 matter,
> 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.
>
>
> 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.
>
>
> WEAK EC GROUPS
> This document specifies the use of SECP160R1. This is not an acceptably
> secure group.
>
> Proposed action: REmove support for 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.
>
>
> 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.
>
>
> 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.
>
> -Ekr



--------------6ADA6DDF40A4D73B7A2B989A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 12px;" lang="x-unicode">Right now I will only reply to
      the AEAD comment.
      <br>
      <br>
      I believe this is directed to the HIP_CIPHER parameter and its use
      in a number of HIP parameter objects.  The ECHO may be encrypted
      with it and in DEX we add the PSK.
      <br>
      <br>
      Since all HIP packets that contain these fields are MACed with
      HIP_MAC, it is deemed that the TLVs within the HIP packet do not
      need to use an AEAD.  In fact RFC already specifies:
      <br>
      <br>
              RESERVED           0
      <br>
              NULL-ENCRYPT       1     ([RFC2410])
      <br>
              AES-128-CBC        2     ([RFC3602])
      <br>
              RESERVED           3     (unused value)
      <br>
              AES-256-CBC        4     ([RFC3602])
      <br>
      <br>
      This is covered in 7401 and an implementer of DEX will know that
      the whole packet is MACed.
      <br>
      <br>
      Other responses to come separately.
      <br>
      <br>
      <br>
      <br>
      On 11/3/19 3:31 PM, Eric Rescorla wrote:
      <br>
      <blockquote type="cite" style="color: #000000;">Sorry for the
        standalone message. I don't seem to be subscribed to
        <br>
        ietf-announce, so can't reply.
        <br>
        <br>
        I do not believe that this meets the security standards that we
        <br>
        currently use for designing protocols at IETF. As a general
        matter,
        <br>
        this document seems to cut a large number of corners in the
        service of
        <br>
        some unspecified "overhead" goal, yet it never describes what
        the
        <br>
        targets are (though presumably this is somehow about computation
        and
        <br>
        bandwidth), and so it is not possible to evaluate the document
        against
        <br>
        them. At present, I am unable to say whether it's necessary to
        do a
        <br>
        new document at all.
        <br>
        <br>
        The rest of this message details specific deficiencies of this
        <br>
        protocol which should be addressed. Aside from these, it's
        fairly
        <br>
        unfortunate to see a design for a protocol that uses such an
        unusual
        <br>
        cryptographic core for no obvious reason. This makes it very
        hard to
        <br>
        analyze. It would be far better to use SIGMA or some other
        <br>
        well-analyzed construction.
        <br>
        <br>
        <br>
        LACK OF PFS
        <br>
        The most serious concern here is the lack of Forward Secrecy.
        This is
        <br>
        a straightforward static-static DH exchange, but it is not
        possible to
        <br>
        provide FS in that scenario, as S 1 acknowledges. I have two
        concerns
        <br>
        here: First, FS is simply table stakes in a modern AKE protocol,
        so I
        <br>
        don't think we should be publishing a document that doesn't have
        it
        <br>
        on the standards track.
        <br>
        <br>
        Second, even if we were to concede that FS might be optional,
        the
        <br>
        design choices here don't make any sense. There are two major
        costs to
        <br>
        DH: the cost of doing the DH computations and the bandwidth of
        sending
        <br>
        the keys. However, given the wide range of the curves permitted
        here
        <br>
        (X25519 to P521), even a full triple-DH protocol will be far
        more
        <br>
        efficient on both counts than the existing protocol with P521
        (indeed,
        <br>
        it's probably as or more efficient than the existing protocol
        with
        <br>
        P256).
        <br>
        <br>
        Proposed action: This protocol needs to be revised to have
        forward
        <br>
        security.
        <br>
        <br>
        <br>
        HIT GENERATION
        <br>
        Previous versions of HIP generated HITs from HIs by computing a
        secure
        <br>
        hash on the HI. This document converts them by a novel folding
        <br>
        procedure. There is no good reason to believe that it is hard to
        <br>
        generate a key that has a given HIT (indeed there are good
        reasons to
        <br>
        believe it <b class="moz-txt-star"><span class="moz-txt-tag">*</span>is<span
            class="moz-txt-tag">*</span></b> reasonably efficient for
        non-EC algorithms). The
        <br>
        document sort-of-acknowledges this in Section 9:
        <br>
        <br>
           o  The HIP DEX HIT generation may present new attack
        opportunities.
        <br>
              Hence, HIP DEX HITs MUST NOT be used as the only means to
        identify
        <br>
              a peer in an ACL.  Instead, the use of the peer's HI is
        <br>
              recommended as explained in Section 3.
        <br>
        <br>
        However, it's not clear it's sufficient, because nothing
        strongly
        <br>
        binds the HI (as opposed to the HIT) to the handshake, so
        attacks
        <br>
        may still be possible if the HI is used (via UKS-like attacks).
        In
        <br>
        any case, this is a regression from HIPv2.
        <br>
        <br>
        It's not even clear why this change was made: given that you
        <br>
        have CMAC, you should be able to use this to produce a hash of
        <br>
        the key.
        <br>
        <br>
        Proposed action: generate HITs from HIs securely.
        <br>
        <br>
        <br>
        WEAK EC GROUPS
        <br>
        This document specifies the use of SECP160R1. This is not an
        acceptably
        <br>
        secure group.
        <br>
        <br>
        Proposed action: REmove support for SECP160R1.
        <br>
        <br>
        <br>
        FAILURE TO VALIDATE PUBLIC KEYS
        <br>
        This document does not require that implementations validate
        <br>
        the remote public key. With the NIST curves specified here,
        <br>
        this leads to straightforward key extraction attacks, which
        <br>
        is a very serious problem when you have a static key.
        <br>
        <br>
        Proposed action: Require point validation. The TLS 1.3 has
        <br>
        text you can borrow.
        <br>
        <br>
        <br>
        AEAD
        <br>
        This document makes use of non-AEAD symmetric algorithms. This
        has been
        <br>
        found to be hazardous in practice.
        <br>
        <br>
        Proposed action: use only AEAD algorithms.
        <br>
        <br>
        <br>
        REPLAY ATTACK ON AKE
        <br>
        The only entropy provided to the AKE is the puzzle, which means
        <br>
        that it's possible for an attacker to replay the responder's
        <br>
        messages, leaving the initiator believing that he has created
        <br>
        a connection when in fact he has not. The attacker will not
        <br>
        be able to send data messages because the initiator contributes
        <br>
        data to the eventual keys, but we generally try to avoid this
        <br>
        property.
        <br>
        <br>
        More importantly, this is unnecessary, and can be resolved
        <br>
        by changing the odd "encrypt half the key" mechanism used here
        <br>
        with a conventional nonce structure in which each side sends
        <br>
        a random value and then you HKDF it with the DH shared secret.
        <br>
        This would have the effect of removing the replay attack
        <br>
        and be easier to analyze.
        <br>
        <br>
        Proposed action: restructure the AKE to mix nonces + DH
        <br>
        into the key schedule.
        <br>
        <br>
        -Ekr
        <br>
      </blockquote>
      <br>
      <br>
    </div>
  </body>
</html>

--------------6ADA6DDF40A4D73B7A2B989A--


--===============8653827995512250906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

--===============8653827995512250906==--