Re: [Secdispatch] Controller-IKE

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE2371200F4 for <>; Mon, 22 Jul 2019 11:14:03 -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 S_RY2vXOMHln for <>; Mon, 22 Jul 2019 11:14:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDA9C1200E3 for <>; Mon, 22 Jul 2019 11:14:01 -0700 (PDT)
Received: by with SMTP id t28so38520102lje.9 for <>; Mon, 22 Jul 2019 11:14:01 -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=zGBWNsVdoIOKVCVYV3pQF1+T8MdbUPGem1shPYv7rKs=; b=iiMcwWK83Azhc6dOPF2co8C+a8AN8mfTuYGImnEUULq40/oLxcXypUMFkzYzWGriIp ITQNLBh/nJ20qluvlP6XkggH7YJvMZ8+gTDllGa4kozFMao/Pd/2fK7deWNExSxwwg/p T4rfSRB5u+6qgEHikjYPPDQEBj0u0RDBLd6InKJ6K4G4Weu5imJ/kmKAFGW9DpZbuQ7e ewLvMw2RTFpauaPN9fEoKZbnZqJ+hFmpTcfvbYPL9gly0OghKeSpY71pudY1hixdob4d 72NIRIqvQk/T+QKagLyv2bfvwRzfhzfQw/o2sDzZVugrRn/BnrLOXZCyyI37k08xv7aQ hCYQ==
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=zGBWNsVdoIOKVCVYV3pQF1+T8MdbUPGem1shPYv7rKs=; b=I+l6O/9O9OrpgORPGu35DrmA4VW0ZM0TxoBjrs/psG0bCtq5rZ64uyAsfrbyuV/C+8 ymXGavNhHovS/PYUNtb4LDtUsrkQR+QSHxe6GqtyTF0ksiBlhDyWTNY3AKfrnicmC//l gBgJqXQoF9nO5TfngklnPQeo3UAdoCRtg0Uv5qbn95A+D+x7CfzHA3jGTnxNuTpc7Jw0 2jQBRvkTBpekpWHDSs3p6t9hpt8l6H+pZHKN+LlXULtqPTKfdRwNIP3qpSHgct+2to2a +EkbUqPWuSbOnUmfSJeQcO3yufM3DmHj2S61cXhAUPk/eA4OPYZw/d28ss8HVEQf6S// 3T0Q==
X-Gm-Message-State: APjAAAVvh0sbThex6fYkSta3hxADkC59c9LN6ZqAgwoodLy/zj08qkQG 0uQlnP7hnSwRJbniSy6F1wbtrpfebYPgWO36q7I=
X-Google-Smtp-Source: APXvYqxb0N1LwU+MyV37LYF2B7lrpY9iux7l4B5ceiYEIIQL5pSqz8kWa3nlVM/5loS4kFPubh5klTmERV3qTlAoehM=
X-Received: by 2002:a2e:8892:: with SMTP id k18mr37626749lji.239.1563819240057; Mon, 22 Jul 2019 11:14:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 22 Jul 2019 11:13:24 -0700
Message-ID: <>
To: "David Carrel (carrel)" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000004bfae0058e490a82"
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 18:14:04 -0000


At the mic today, you said that C-IKE was 2N complexity rather than N^2
complexity in terms of messages. Here's what confuses me.

Just for simplicity, imagine that we do this in two phases: everyone
registers their key with the controller and then the controller
disseminates them. At this point, the controller has N keys and it needs to
send them to N endpoints. If you are able to broadcast to all the nodes at
once, then the controller will send N keys, so the total overhead is 2N (N
uploads + N downloads). However, if the controller has point to point
links, then the controller has to send ~N^2 keys (N-1 keys down N links).
So those might be bundled into a single message, but you still have to send
N^2 keys. Or am I missing something?


On Mon, Jul 22, 2019 at 10:27 AM Eric Rescorla <> wrote:

> Thanks for clarifying. With that said, it's possible to do better than
> this if you use a conventional AKE and time out associations somewhat
> aggressively.
> -Ekr
> On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) <>
> wrote:
>> * 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).
>> True, the DH load can be expensive, but no more so than an equivalent
>> mesh of traditional IKE.  We would not need to re-key any less often.  I
>> believe this makes the PFS story equivalent.
>> This doesn't seem correct to me. Consider the case where you do pairwise
>> IKE and then delete the SA and the DH ephemerals. At this point, compromise
>> doesn't leak the traffic keys at all. By contrast, in Controller-IKE
>> because I need to store my DH share indefinitely in case a new peer comes
>> online, then that represents a long-term source of compromise.
>> OK, I think this is where you misunderstood something or we didn’t
>> explain well enough.  There are no long-term DH keys in Controller-IKE.
>> All are ephemeral.  It is true that due to synchronization, you will likely
>> keep them a little longer, but never more than 2 key lifetimes.  If you
>> re-key every 2 hours, then the worst case is that your DH values are kept
>> for 4 hours.
>> Dave