Re: [Secdispatch] Controller-IKE

Eric Rescorla <> Mon, 22 July 2019 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3132120396 for <>; Mon, 22 Jul 2019 07:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HYiitEST6UjM for <>; Mon, 22 Jul 2019 07:32:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7DCA120331 for <>; Mon, 22 Jul 2019 07:32:30 -0700 (PDT)
Received: by with SMTP id v85so26772854lfa.6 for <>; Mon, 22 Jul 2019 07:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=petWBepd+z7rTabHUo4yc75aIKiLQFeXDQrFrZDx018=; b=oppw/q9mQmPpqFuREMK4L0Iu75RCCYrnP9cEUEOCTLmosQHHRY5tjBZMZ/wwhCxKSy YHPXzX3blRrsejE+eUkO5eO2PvEppE+y4ZiHG4UcVzIo+EP4RRN1gP5zQy0eU0Ssv/Gr N/9xHcIZgOjUypBNjkq3D5IggHK+Ob1cvKto/ODRJsZBLbCsqyKiasF0+jDTfKfTwgKf eWea8Yh4FAL4b4Ryx9wWNI2Ja6+yOdg5H/J+nhmZGapNJMDMvRBXeXQNeK6adIYillI0 1jNPmThCWtNpuP2if3+ugeQy8YL0ynLoXgyDAzKncSyDcQLp3DAHYJhw+QxxT1eHqvAk ahug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=petWBepd+z7rTabHUo4yc75aIKiLQFeXDQrFrZDx018=; b=SJ5fPYICWEOXzTVWbuhB0F2Lgdl7m4J0o1fnNE9IeE7h2080WVMKNgj2o296qUKhcJ b2MmJeB7qicquLSUofskMDJYBcSJOdm2WQHi+oDGmWSLm0elfbIFWhgao4zpaPfvTrJ9 RwKPN9/McuZMfDqdlrrrxW7RRsMuE5NhX3BmGilq3EyrhTy9PLCmIvOWpgi7aMi3OuO4 cP9Vdi1x9htmiDdckCZBVhB1iQNy38/KKA5bzQ231JJaJZU/msTcJUputp0HpMpFVFGO c4QaLFLr8Nqo3u43vfnPeYDVCEcE/YHP1ISRvKse1U7YKG4+r1HDx/2u5E9J7n9gQ+WF TmQg==
X-Gm-Message-State: APjAAAWnrc60KRKb2fsvkusjy3sgJOmMDN2AKXanjt0Mb3Ep90ML7F83 eTvJBAKDI8z96r/tHzFccTa8zYSKQ6OPi3Axo+s=
X-Google-Smtp-Source: APXvYqxE4i2Yd7xoC+n3VJDlByRU1WZwiR+WKboWglKfmjI/lxOuboBU6EtnFlQ/dGM+pIgaIyrFDovC7PpCevbjpeA=
X-Received: by 2002:ac2:528e:: with SMTP id q14mr30045037lfm.17.1563805949161; Mon, 22 Jul 2019 07:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 22 Jul 2019 07:31:52 -0700
Message-ID: <>
To: "David Carrel (carrel)" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000190665058e45f264"
Archived-At: <>
Subject: Re: [Secdispatch] Controller-IKE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2019 14:32:35 -0000

Document: draft-carrel-ipsecme-controller-ike-01.txt

I took a quick look at this document, and I have a few thoughts,
in no particular order.

* I understand the desire to think of this as an extension
of IKE, but it's actually pretty different, and I'm not sure
how much leverage you are getting from trying to make them

* I think it would be useful to be a little clearer about what
resource you are trying to conserve here. I get that using straight
IKE would require N^2 associations, but this does as well. It doesn't
require N^2 protocol exchanges, but it requires N^2 DH operations (if
everyone wants to talk to everyone else). So, the main value seems
to be that you can send to someone in 0-RTT without exchanging
any messages beforehand. Is that correct?

* The PFS story here seems pretty bad: I'm assuming that people
aren't going to change their DH keys very often (as it's extremely
expensive for everyone else).

* What happens if node A takes node B's DH key and nonce and
advertises them as its own? If I understand the draft correctly,
C will end up with the same SPKI and keys between C-B and C-A.
Is that right? If so, that sounds at minimum like an identity
misbinding attack, but if you are using implicit IVs
then wouldn't you get nonce reuse, which would be quite bad.

* You also seem to have a KCI problem, where if your keys is
compromised, an attacker can impersonate anyone to you.

ISTM that you would be in a better position if you adopted a 0-RTT DH
flow in the style of OPTLS. I.e., A and B each have keys g^a, g^b and
you mix them in with ephemeral DH keys g^x and g^y. This kind of
exchange is reasonably well studied, and has good PFS and key
confirmation properties. You can piggyback the key establishment
messages along with the data you want to send, so you'll still get
data on the first message.


On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) <>

> Folks,
> I would like to present Controller-IKE in the Montreal Security Dispatch
> meeting.  There is growing interest from routing folks, and I strongly feel
> we should evaluate and progress this in the security area.  I’ll have some
> slides to share shortly.  For now, please do read the draft.  Also there
> are some drafts referencing this:
> Controller-IKE:
> Also some docs referencing this form of key management:
> BESS, Secure EVPN:
> And:
> Comments appreciated.
> Dave
> _______________________________________________
> Secdispatch mailing list