Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

[Randy Bush <[e-mail]>]

>> but this is a tangent.  the point is that protocols which rely on
>> keying really need to nail the key distribution model(s).
> I agree. But I think one of the issues here is that we don't (afaik)
> have a worked out analysis of how various key distribution models play
> with DHCP.
>> while tofu may be one, is it really one that security folk think the
>> ietf should advocate for set-up authenticity?  it's not how i want to
>> make the wsj; and coffee shop mitm will be in the wsj soon enough.
> Fair enough. OTOH, I don't think there will be one key distribution
> model that will work well for all DHCP deployments.

which is why i said "(s)" above.

> So we may end up having to specify a set of mechanisms, when each is
> suitable to use and the security considerations resulting. That's a
> chunk of work, and a chunk of work where these authors are looking for
> help.  I do hope someone's going to volunteer to help them with that.

the problem is, as i said in the meeting, we have a poor track record
here[0].  not a lot of good examples from which to steal.  and i am not
sure picking on dhcp is a good iconic example.  have you looked at the
anima wg?

but back to picking on dhcp, :)

within an enterprise, one is tempted to suggest enterprise-controlled
credential distribution; i get a cert (or whatever) oob to let my laptop
authenticate the dhcp service and vice versa.  but enterprises are
seeing a lot of byod, and i am not sure how they are dealing with that.
do they really want to authenticate all mobiles?

in the coffee shop, one would like the mobile device to be given the
dhcp server's credentials out of band; i suggested a QR code on the wall
as one (i.e. there could be others) example.  and, unlike the
enterprise, i think the mobile device should reveal as little as
possible about itself.

bottom line: i do not think there are easy solutions in the introduction
space.  but it is our responsibility.  and i am trying to think about
it and others should too.

randy

--

[0] - i am remonded of the plethora of documents with insecure
      transports where the sec cons says "use ipsec" with no hint about
      keying, how the upper layer can even tell if ipsec is being used,
      ...