On 09/19/2014 07:52 AM, Steven Barth wrote:
Am 19.09.2014 um 16:29 schrieb Michael Thomas:
Punting on one of the hardest problems would be a travesty. There are
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to
do the right thing again if we loose
this into the wild and say "figure it out yourself." We know what
happens then.
That was not my point. I'm totally happy with having a standardized
way of doing this but I don't think that HNCP is the place where it
should be defined since we will probably not be the only user. Don't
get me wrong if we or anyone else comes up with a brilliant solution
I'm all up for referencing it and using it. For HNCP itself what is
more important to define in my mind is choosing the crypto-mechanism
or at least I would separate those two discussions.
HNCP or Homenet in general? Given the possibility of leveraging key
distribution and/or auth/authz information from
HNCP itself, it might not be bad to consider the homenet security issues
organically. However, if this is a plea for
kicking this down the road to some non-existent working group, I don't
agree at all, and nor do I think that the
architecture would permit that.
The other point is, it doesn't matter how technically brilliant the
solution is in the end if the user experience isn't good enough and
that is outside our control really. Adding to that judging from
experience with consumer-oriented hardware, if we get HNCP adopted
then the baseline of products will probably support no-auth or maybe
PSK if we are lucky unless we actually forbid unencrypted HNCP and /
or PSK-secured HNCP and I'm not sure I personally would want to go
there really.
This is the danger of saying later, or even a "YOU MUST IMPLEMENT RFC
XXX TOO" requirement. We've seen this
way too many times in the past and it will be a complete mess if don't
take a hard line, IMO.
Mike
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
