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

[Stephen Farrell <[e-mail]>]

Hi Randy,

On 29/07/15 08:16, Randy Bush wrote:
> this document, like the v4 dhc document, is all mechanism with no clear
> statement of applicability.  neither document discusses key distribution
> and management, the usual critical fulcrum of symmetric and asymetric
> key-based mechanisms.  e.g. how does this work in a coffee shop?  and
> the answer better not be tofu and leap of faith.

I'm not keen on that kind of argument tbh where we say "show me your
threat model and btw <this> better not be it." Can you Randy show me
a good analysis of how different kinds of key management have which
consequences for DHCP authentication and confidentiality? I don't
believe I've seen that documented myself but I've not spent time
looking specifically for it. In this case the authors are looking to
us for help with getting that done, and I don't believe poking them
like that is either useful or fair, sorry.

As for TOFU, I do believe there may be a role for that in DHCP. There
are cases where I informally start to use a sadly-open WiFi n/w and
continue to use that for a few days or sporadically  (e.g. a friend's
guest WiFi) and in such cases TOFU could provide some protection to
some or maybe most of the population using such a network. (And even
if my friend has WPA turned on, TOFU for DHCP might protect me from
their clever kid who was in school when I arrived;-) It'd also not be
reasonable to expect my friend to have asked permission from a CA
before setting up the guest WiFi.

And yes, there are enterprise cases where a local PKI could and maybe
should be used instead. And yes one could argue that WiFi roaming
arrangements and large franchises (e.g. starbucks) should find a way
to put certs in place, but I'm not convinced that doing nothing until
we reach that goal is reasonable. I am fairly convinced that always
requiring use of a PKI would result in fairly ubiquitous lack of use.

There may even be good arguments based on the nature of DHCP to the
effect that I'll have to accept what TOFU would tell me to reject, but
I also don't think I've seen that either. (When my putative friend
above buys a new AP/DHCP-server that would be an issue for either TOFU
or a PKI based answer, but perhaps not an insurmountable one in either
case.)

But we (the IETF) have a really bad history with DHCP security in that
RFC 3118 [1] is perhaps the most commonly cited unused security RFC.
One could I think claim it wins the security-BS contest for RFCs
even shoving the evil bit down into 2nd place;-)

Forty-seven (yes 47! [2]) other RFCs reference 3118 and that mostly
means pretending to provide security via a reference that the authors
fully know is BS. I have checked a number of times with such authors
and 3118 seems comprehensively unused. I only ever got one .mil type
person saying that they use it but he wasn't allowed say more. Nobody
else has ever told me that they can or do use 3118. In fact, in most
cases when I see a reference to 3118 as a security mechanism, I'll
put on a DISCUSS ballot to call the authors out for the BS. And in
many cases we find they just copied it from somewhere hoping it'd
shut-up the security ADs;-)

We can certainly improve on that sad state. And I would say that
TOFU is a credible part of that until evidence or detailed argument
to the contrary is produced, which you have yet to do.

S.

[1] https://tools.ietf.org/html/rfc3118
[2] http://www.arkko.com/tools/allstats/citations-rfc3118.html


> 
> randy
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>