Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Ted Lemon <mellon@fugue.com> Wed, 07 June 2017 19:09 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8BB12946A for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 12:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 mqwb8Oz2t1XD for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 12:09:30 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9490213146E for <dhcwg@ietf.org>; Wed, 7 Jun 2017 12:06:12 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id u19so17223900qta.3 for <dhcwg@ietf.org>; Wed, 07 Jun 2017 12:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.55.104.129 with SMTP id d123mr3398334qkc.176.1496862371608; Wed, 07 Jun 2017 12:06:11 -0700 (PDT)
Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q41sm1626154qtc.8.2017.06.07.12.06.10 (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 <mellon@fugue.com>
In-Reply-To: <201706071835.v57IZETv059955@givry.fdupont.fr>
Date: Wed, 7 Jun 2017 15:06:09 -0400
Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, dhcwg <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D820E666-0948-44C9-A221-DE497E2BABFE@fugue.com>
References: <201706071835.v57IZETv059955@givry.fdupont.fr>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/MtRzHdEjIJp8wm5bVPIPc9_asTY>
Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=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 <Francis.Dupont@fdupont.fr> 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
> 
> Francis.Dupont@fdupont.fr
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg