From nobody Sun Nov 3 12:34:29 2019 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7012008C for ; Sun, 3 Nov 2019 12:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxJxdwVmfAgB for ; Sun, 3 Nov 2019 12:34:25 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CE8120073 for ; Sun, 3 Nov 2019 12:34:24 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id j14so10693226lfb.8 for ; Sun, 03 Nov 2019 12:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u+K6KvEA3IR7Xq/MG9hbzdLZmjia2fzimGnetYv5mtQ=; b=mN0ktf1i4XZp9mmh6iAswjjAX5Dyqw43BR3w24RpVWcrxQFSBhMBR0l+k5JbISoPEh 7lYO0WnBFjpwuqD8yxbrew3qiLG19uJPc7rlDxrHUi8NZgq6A8eh/wnuPrZEOA9QwREV GfQ0EyuATQDqZmTfmWctoQsc4YdXy4h89bV6ltIpJdMEv29u/MD6+qTYOK+pH2Wq4Fcg 77VU2O76KOvaHJbsNeK/7cucRcQ8Rg/s3TGm7TkqRjDZ8Qpy7jncp4w36/oIKXEaiIay bJDxqfJ4vo/tgY+cMY+yywDMMc/al5BdhXRMLawt3+b7K7bbTeNP3qy18n/vkj3w/Rsw 2B+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u+K6KvEA3IR7Xq/MG9hbzdLZmjia2fzimGnetYv5mtQ=; b=Ts2N1jyS0r83yE4Nqz6spZT/ocNXl/H2FWRPmYagwiPnNpxi9xHy6UmuuWZCZawwpC n/w3UDZuvPvcWcgBZ5mIyERPfLpg3LIXCQaB7FLk4ePcz07LgDqfPshAT2AtCxRA/Uu1 k4atYDtSMSvD59U6fAjUltJ9Nau10uqp4XKPuEeDbnHQ6GRzjNCrFdx9nb+QHapKsVuD acbEWM9mMXqtOUwnl6vc3N8b1sT2gRnfRmjRkBBZbnwQ58SZ2XEoc0NCULNVaBPcslzG XW0pMeiLD3zy6PxyK7cfoXfYP1QuQSnhhp8G/YGo1Xt4yoermS2+tfs9L8tVjPGxtgh4 wCDw== X-Gm-Message-State: APjAAAVwXVKjsjgpkf9CyTSkaFS/tT0vMTimEs4NO4gVgbz2/KV8hY2N 0FrGStNVqCYmoJU66NGFtmC8t3uF6FMO4o1wpkOCOttF X-Google-Smtp-Source: APXvYqyq//O7guRfRu9F86c42WPsB/vkuSr0Ev8crRYtPtMaPHr94uworrnYuLHCrnH1wbfnYepfQotbDPDOenPcGEo= X-Received: by 2002:a19:f107:: with SMTP id p7mr13788833lfh.91.1572813262354; Sun, 03 Nov 2019 12:34:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 3 Nov 2019 12:33:45 -0800 Message-ID: To: hipsec@ietf.org Content-Type: multipart/alternative; boundary="000000000000cd10bd0596771f0b" Archived-At: Subject: [Hipsec] Fwd: Last Call comments on draft-ietf-hip-dex-11 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 20:34:27 -0000 --000000000000cd10bd0596771f0b Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Eric Rescorla Date: Sun, Nov 3, 2019 at 12:31 PM Subject: Last Call comments on draft-ietf-hip-dex-11 To: , , , IESG 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 --000000000000cd10bd0596771f0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, Nov= 3, 2019 at 12:31 PM
Subject: Last Call comments on draft-ietf-hip-dex-1= 1
To: <last-call@ietf.org&= gt;, <draft-ietf-hip= -dex.all@ietf.org>, <hip@ietf.or= g>, IESG <iesg@ietf.org><= br>


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 th= at 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 an= d
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 d= eficiencies of this
protocol which should be addressed. Aside from these= , it's fairly
unfortunate to see a design for a protocol that uses s= uch an unusual
cryptographic core for no obvious reason. This makes it v= ery hard to
analyze. It would be far better to use SIGMA or some otherwell-analyzed construction.


LACK OF PFS
The most serious co= ncern here is the lack of Forward Secrecy.=C2=A0 This is
a straightforwa= rd static-static DH exchange, but it is not possible to
provide FS in th= at 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 s= hould 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 moreefficient 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 fo= rward
security.


HIT GENERATION
Previous versions of HIP ge= nerated HITs from HIs by computing a secure
hash on the HI. This documen= t 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-E= C algorithms). The
document sort-of-acknowledges this in Section 9:
<= br>=C2=A0 =C2=A0o =C2=A0The HIP DEX HIT generation may present new attack o= pportunities.
=C2=A0 =C2=A0 =C2=A0 Hence, HIP DEX HITs MUST NOT be used = as the only means to identify
=C2=A0 =C2=A0 =C2=A0 a peer in an ACL.=C2= =A0 Instead, the use of the peer's HI is
=C2=A0 =C2=A0 =C2=A0 recomm= ended as explained in Section 3.

However, it's not clear it'= s sufficient, because nothing strongly
binds the HI (as opposed to the H= IT) 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
h= ave 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 acce= ptably
secure group.

Proposed action: REmove support for SECP160R= 1.


FAILURE TO VALIDATE PUBLIC KEYS
This document does not req= uire that implementations validate
the remote public key. With the NIST = curves specified here,
this leads to straightforward key extraction atta= cks, 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 al= gorithms. This has been
found to be hazardous in practice.

Propos= ed 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, leav= ing the initiator believing that he has created
a connection when in fac= t he has not. The attacker will not
be able to send data messages becaus= e 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&quo= t; 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 secre= t.
This would have the effect of removing the replay attack
and be ea= sier to analyze.

Proposed action: restructure the AKE to mix nonces = + DH
into the key schedule.

-Ekr







<= br>











--000000000000cd10bd0596771f0b-- From nobody Sun Nov 3 12:58:43 2019 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DCE1200C1 for ; Sun, 3 Nov 2019 12:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsIPoPPK8wRW for ; Sun, 3 Nov 2019 12:58:39 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB67A12002E for ; Sun, 3 Nov 2019 12:58:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F32796210D for ; Sun, 3 Nov 2019 15:58:37 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HnglTnYrM9HD for ; Sun, 3 Nov 2019 15:58:25 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B05D861FDB for ; Sun, 3 Nov 2019 15:58:25 -0500 (EST) To: HIP References: From: Robert Moskowitz Message-ID: Date: Sun, 3 Nov 2019 15:58:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6ADA6DDF40A4D73B7A2B989A" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Fwd: Last Call comments on draft-ietf-hip-dex-11 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 20:58:41 -0000 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
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-- From nobody Mon Nov 18 22:37:50 2019 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D59120876 for ; Mon, 18 Nov 2019 22:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hW-nzoKB_7b for ; Mon, 18 Nov 2019 22:37:44 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD7E12087C for ; Mon, 18 Nov 2019 22:37:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2578F62111 for ; Tue, 19 Nov 2019 01:37:43 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id T0-sTKs7Nkeo for ; Tue, 19 Nov 2019 01:37:37 -0500 (EST) Received: from lx140e.htt-consult.com (dhcp-9f34.meeting.ietf.org [31.133.159.52]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 576B7620D4 for ; Tue, 19 Nov 2019 01:37:36 -0500 (EST) To: HIP From: Robert Moskowitz Message-ID: Date: Tue, 19 Nov 2019 14:37:31 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Hipsec] TM-RID progress X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 06:37:49 -0000 Fellow HIPsters: The TM-RID BOF went well.  The opinion is to charter TM-RID as a new workgroup.  It will be doing a number of addendum to HIP. Please join the tm-rid@ietf.org list to participate. Bob From nobody Sun Nov 24 22:38:52 2019 Return-Path: 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 2127C1207FE; Sun, 24 Nov 2019 22:38:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Michael Richardson via Datatracker To: Cc: last-call@ietf.org, draft-ietf-hip-dex.all@ietf.org, hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Michael Richardson Message-ID: <157466392692.32744.2341419042914872690@ietfa.amsl.com> Date: Sun, 24 Nov 2019 22:38:47 -0800 Archived-At: Subject: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 06:38:47 -0000 Reviewer: Michael Richardson Review result: Ready I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex I reviewed the -11 version. I did not identify any technical problems or gaps. The introduction tells that I won't understand this without a good understanding of RFC7401 (HIPv2). I went ahead anyway, given that I did know HIPv1 (RFC5201) and IKEv2. While it is clear that I could not implement without knowing 7401, I did find that I could understand most of the goals, the compromises that were made to reduce the complexity for constrained environments. I did go back and read 7401 in the end to fill in a few gaps. Particularly I really needed to understand RFC7343 HITs of the new type, and I did not manage to understand that part. I observe that a new ECDH type of HIT is defined, but I did understand how these values would be exchanged/stored or looked up. I would appreciate a use case or two which has been sufficiently built-out so that I can see the whole picture. If ECDH HITs come from DNS (via AAAA records) for instance, then I'd appreciate an understanding if/how the constrained device is able to leverage DNSSEC. In particular, I'd like to know what kind of applications are ruled out by lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS. Would this document play well with draft-ietf-ipsecme-implicit-iv? I am unclear if the diet nature of DEX is more about: (1) constrained/challenged networks (2) constrained/slow CPUs (3) systems with very minimal amounts of flash (1) networks have often very small packet sizes, and I would appreciate understanding the total frame sise of each I1/R1/I2/R2, and any impact that fragment assembly might have on the statelessness of the I1/R1 exchange. I know that HIP has be profiled for use in 802.15.9, and I assume that HIP DEX is even better, but the lack of PFS might be a show stopper. (2) slow/sleepy CPUs are not going away, but the amount of available flash on rather cheap, small and sleepy devices is now in the multiple megabytes, so it is unclear if further code simplications are worthwhile. My questions should not stop the document from advancing.