Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  On Jun 7, 2017, at 5:25 PM, Francis Dupont <[e-mail]> =
>  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).

Regards

[e-mail]

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