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

Eric Rescorla <ekr@rtfm.com> Sun, 03 November 2019 20:34 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 46B7012008C for <hipsec@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FxJxdwVmfAgB for <hipsec@ietfa.amsl.com>; 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 <hipsec@ietf.org>; Sun, 3 Nov 2019 12:34:24 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id j14so10693226lfb.8 for <hipsec@ietf.org>; 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: <CABcZeBNQeT8jiYE=nHFqm57-Z5oq9qm29XDJupFkRDTi+i_pXQ@mail.gmail.com>
In-Reply-To: <CABcZeBNQeT8jiYE=nHFqm57-Z5oq9qm29XDJupFkRDTi+i_pXQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 3 Nov 2019 12:33:45 -0800
Message-ID: <CABcZeBMRptoaGhgWYmC8a=9tBjoJxVBYbge7EF1xBY7c0poWXQ@mail.gmail.com>
To: hipsec@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cd10bd0596771f0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/gVWcpu4jL-aEI0HZpVJ_PfDSdlc>
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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2019 20:34:27 -0000

---------- 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-11
To: <last-call@ietf.org>;, <draft-ietf-hip-dex.all@ietf.org>;, <hip@ietf.org>;,
IESG <iesg@ietf.org>;

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.

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

Proposed action: This protocol needs to be revised to have forward

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.

This document specifies the use of SECP160R1. This is not an acceptably
secure group.

Proposed action: REmove support for SECP160R1.

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.

This document makes use of non-AEAD symmetric algorithms. This has been
found to be hazardous in practice.

Proposed action: use only AEAD algorithms.

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

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.