Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Francis Dupont <> Wed, 07 June 2017 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B59E131458 for <>; Wed, 7 Jun 2017 11:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zhy3YGRAXNJt for <>; Wed, 7 Jun 2017 11:52:50 -0700 (PDT)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CDB5127337 for <>; Wed, 7 Jun 2017 11:50:03 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id v57IZETv059955; Wed, 7 Jun 2017 20:35:14 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
cc: dhcwg <>
In-reply-to: Your message of Wed, 07 Jun 2017 11:10:52 -0700. <>
Date: Wed, 07 Jun 2017 20:35:14 +0200
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 18:52:51 -0000

 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...