Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Francis Dupont <> Wed, 07 June 2017 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AE681270B4 for <>; Wed, 7 Jun 2017 16:17:29 -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 A_C0KE8yMxKg for <>; Wed, 7 Jun 2017 16:17:27 -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 3F826126D45 for <>; Wed, 7 Jun 2017 16:17:27 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id v57N2XbZ076691; Thu, 8 Jun 2017 01:02:33 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Ted Lemon <>
cc: Tomek Mrugalski <>,
In-reply-to: Your message of Wed, 07 Jun 2017 17:49:25 -0400. <>
Date: Thu, 08 Jun 2017 01:02:33 +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 23:17:29 -0000

 In your previous mail you wrote:

>  On Jun 7, 2017, at 5:25 PM, Francis Dupont <> =
>  wrote:
>  > I am afraid you are replacing the address bootstrap mess by the =
>  security
>  > bootstrap mess but there is a security protocol which includes address
>  > bootstrapping, it is IKEv2 so IMHO we should try it as on the paper
>  > it has all we need.
>  Pretty much everything you said here assumes that the DHCP client has a =
>  routable address.

=> requiring a routable address is what I called the "address bootstrap" mess.
Note we don't need one, just to be able to send a packet to the server
and if possible not using multicast (multicast is where the embedded
relay can help). Note that IKE or DTLS works over link-local addresses
so you can protect directly client-relay.

   It's the fact that it doesn't that makes this hard.

=> yes, the info-request / stateless case is easier.

>  Also, a key agreement protocol is probably not a good idea if we care =
>  about privacy.

=> by key agreement I mean a Diffie-Hellman variant (more ECDH or X25519).
Cf Russ Housley's message.
I can't see what is the impact on privacy: it is just a parameter saying
which variant, and a public random/opaque value which can be changed for
each init (DISCOVER/SOLICIT) message.

>  And we already talked about how to do TOFU, and I think that applies =
>  just as well here as to the current spec.

=> TOFU is a server policy.

Another problem with all IKE, DTLS and reinvented similar mechanisms
is that it is not possible to protect both identities against active
attacks (cf the SIGMA conf paper) so if we want mutual authentication
we have to choose protocols which protect the client/initiator identity
(for instance to put the client public key in clear text in the first
message is not good even against passive attacks).


PS: as candidates with have  HIP, and also some EAP/PANA extensions
to do encryption (IMHO more to get ideas than to use).
PPS: before going further it seems we should first agree about what
we want...