Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Ted Lemon <> Wed, 07 June 2017 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D8BB12946A for <>; Wed, 7 Jun 2017 12:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mqwb8Oz2t1XD for <>; Wed, 7 Jun 2017 12:09:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9490213146E for <>; Wed, 7 Jun 2017 12:06:12 -0700 (PDT)
Received: by with SMTP id u19so17223900qta.3 for <>; Wed, 07 Jun 2017 12:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+28SdvCJs/hdODkW8swpzs6xSCWiB2iVFPhDWHwdFY=; b=ChkBhpxhJwOcpFVmNI9oZggHxBM8KZhaSqWUb8M1AKaJMTZ1M7m/uq6ueed02GBY0H hC1u4LftPLqzRPUXr0HDfjbkIxWI8K7ZqJL9CeIgKHymyaRdhEF6RGV3cKLk9P/kTL+k aA9hsmLZ7k4dtVSsVdgYb4UWmwkdUqyq/YyfeiWqZGQgzXQRAbAqJ9pS0yMcxDAvpC0w nQRuZIpXRmLNEi8jWewKZU1JCNFDs5aBuqPIG9ITS4e/k24SYpfmDLUiNb8lGKrki+JF wXAIzdcdABXnrzweiKFYjuj7VUKq/TorZw6zse6P7iT39m16gHQZeU6e1jHGmPspKU2x yxiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+28SdvCJs/hdODkW8swpzs6xSCWiB2iVFPhDWHwdFY=; b=VFGDEHU6sYqmu84/rTIIpBGtmDw3R33fYPWs6EJWPALj0mYJS28DLVq7G14iqd4s0c nUnLmMyzAMWaLlgfRX6iiXHvIc1pN4kdRCbmsrrvwCDxbRfy/Z77rXbWKc4rI5FbYJci H/2fCvqSEPcCGUaG9ojLcrMWDD26kytDk3EQ/CFcteUAZASuVOpzyZqFEh8sY03ydSfo hP9iaAmYr+LEyCYntDIr0W2KL6cWuFyK3gxOrXlFaFgpFxbD2/iZOU5HR+U14VX5LJiu 0kMmti0GM3s0hSN4tAO1/emptL7NdY7pg6fLLMY0mqAedaugxlNIAxsiKtCKQxzW90uc YSUQ==
X-Gm-Message-State: AKS2vOyEEs+TIjVovQuajO5zjVbCJsp8cOVwgCESqBLIPQFcPgZXsCWk egtmOH0XQ3bd/eem
X-Received: by with SMTP id d123mr3398334qkc.176.1496862371608; Wed, 07 Jun 2017 12:06:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q41sm1626154qtc.8.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 12:06:11 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Wed, 7 Jun 2017 15:06:09 -0400
Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= <>, dhcwg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Francis Dupont <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2017 19:09:32 -0000

Bernie addressed the key issue.   I think Bernie's suggestion is fine, but sounds a lot like DTLS, which begs the question, why not just use DTLS?   And Francis, much as we might wish it otherwise, IPsec isn't actually a practical option as far as I can tell.  I have no idea how to use it for anything other than setting up a VPN on, e.g., Mac OS X.   If you have a resource to point to on that, I'd be interested to hear about it.

> On Jun 7, 2017, at 2:35 PM, Francis Dupont <> wrote:
> In your previous mail you wrote:
>>> => it is more than a fundamental issue: the idea to use RSA encryption
>>> is simply a deadly bad one...
>> Could you explain it in more detail?  Is it just about the particular
>> choice of algorithm (RSA), or is it about the use of asymmetric
>> (public-key)-based encryption to encrypt DHCPv6 messages in the first
>> place?  And why is it bad?
> => in fact it is both because RSA is the only asymmetric algorithm
> which provides an accepted encryption feature.
> Now why it is bad (other than RSA has no future)? Just because it was
> designed to protect something short as a key for a symmetric encryption
> and *not* for a message with an unbound length.
>> If it's the former, (depending on the reason) we might choose a better
>> algorithm as the default/mandatory.
> => as I explained I am afraid there is no alternative which went further
> than conference papers...
>> If it's the latter, we could revise the protocol so it will first
>> negotiate a symmetric session key using public-key based encryption
>> and use the session key for subsequent DHCPv6 message exchanges.  That
>> will be a quite substantial change from the current spec, but I guess
>> it's not impossible.
> => if you go to a key agreement phase followed by symmetrical encryption
> I am afraid you are reinvented something which already exists so why
> not investigate current possible solutions and try to use them directly?
>>> Perhaps we should drop it and restart from the beginning about
>>> address assignment security, for instance using opportunistic DNSSEC
> => oops? I wrote DNSSEC? I wanted to mean IPsec.
>>> with a client embedded first relay? At least it does not need to
>>> develop a new protocol...
> Regards
> _______________________________________________
> dhcwg mailing list