Hiya, On 24/01/18 15:36, Ted Lemon wrote: > Yes, enrollment is the process by which trust is established. Google > home has an example, but it's rickety. It's actually not too bad for > actual Google devices, but the third party enrollment process could > really benefit from some open standards (imho).
While I don't disagree with you, I do still wonder if we'd not be better off using another term for cases where maybe all that are involved are a couple of routers in the home, and where there's no external party, such as google in the example you give. The reason I'm on about this is that if we use terms like "trust" and "enrollment" without qualification, then we may end up meaning quite different things, which might then make it harder to try find some solutions to what are in any case all hard problems. Cheers, S. > >> On Jan 24, 2018, at 10:03 AM, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> On 24/01/18 14:55, Ted Lemon wrote: >>> I don't know what unmanaged enrollment really looks like, but >>> sure. We've mostly been talking about models for managed >>> enrollment, and that seems to be the way the market has been >>> going (with remarkable suck-itude, if the Google Home enrollment >>> process is typical). >> >> A question for ya: I'm not sure if by "enrollment" you include such >> things as two routers deciding to agree that some key material is >> sufficient for subsequently protecting hncp or babel packets >> between themselves? (I don't want to get into discussion now as to >> how either might happen, I just wonder if we'd be better off using >> different terms for these problems.) >> >>> I think it might be worth having someone give a presentation on >>> the anima enrollment model, if someone is willing to do that. >> >> Sure. If someone wants to volunteer to do that, just ping Barbara >> and I and we can throw that into pile for agenda construction. >> >> Cheers, S. >> >> >>> >>>> On Jan 24, 2018, at 8:51 AM, Stephen Farrell >>>> <stephen.farr...@cs.tcd.ie> wrote: >>>> >>>> >>>> Hiya, >>>> >>>> On 24/01/18 13:32, Michael Richardson wrote: >>>>> >>>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: >>>>>> On 24/01/18 02:48, Michael Richardson wrote: >>>>>>> >>>>>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > - >>>>>>> Does this sound roughly right or off the wall? >>>>>>> >>>>>>> It sounds right. I think that bootstrap of security >>>>>>> should become an recharter item in the future. Some kind >>>>>>> of BCP on interactions with MUD, SUIT, etc. IN THE >>>>>>> FUTURE. NOT NOW. >>>>> >>>>>> Can you say more? Eg. what would be needed before you >>>>>> think it'd be sensible for homenet to start work in this >>>>>> space? >>>>> >>>>> a) finish (really finish) Babel work, that might mean >>>>> interacting with BABEL WG >>>>> >>>>> b) DNS naming and delegation in Last Call. >>>>> >>>>> c) ANIMA and related groups publish *managed* enrollment, so >>>>> that HOMENET can consider how *unmanaged* enrollment might >>>>> work. >>>> >>>> Reasonable points. Do others (dis)agree? >>>> >>>> Without a chair hat on, I'm not sure that some of those other >>>> bits of work need to be fully finished - if we know what kind >>>> of keying that'll be used in the final results, we could make >>>> some progress, but I do agree we'd need to know e.g. whether >>>> Babel implementations would plan to support what flavours of >>>> DTLS (e.g. pre-shared keys vs. bare public keys vs. certs if >>>> they do plan to use DTLS), and other similar things, so I tend >>>> to agree those bits of work would need to be at least >>>> nearly-done. >>>> >>>>> >>>>>>>> 2. We have this milestone in our charter: >>>>>>> >>>>>>>> "Nov 2018 - Submission of the perimeter security draft >>>>>>>> > to the IESG >>>>>>> as Informational RFC" >>>>>>> >>>>>>> Yes. Are the authors still engaged? >>>>> >>>>>> I'm not aware that we have authors;-( I guess someone >>>>>> could have volunteered in the past before I was helping out >>>>>> as chair (if so, please do let us know). >>>>> >>>>> Ah, so it was Erik and some other people. I see that the >>>>> draft has even expired. I'm thinking about: >>>>> https://datatracker.ietf.org/doc/draft-kline-homenet-default-perimeter/ >>>>> >>>>> >> >>>>> Maybe you are thinking about something else? >>>> >>>> Nope, I'd not seen that draft before. >>>> >>>> Do others still consider we should work on this topic? (based >>>> on that draft or not) and we'd still like to know who's willing >>>> to do stuff, if so. >>>> >>>> Cheers, S. >>>> >>>>> >>>>> -- ] Never tell me the odds! | >>>>> ipv6 mesh networks [ ] Michael Richardson, Sandelman >>>>> Software Works | network architect [ ] m...@sandelman.ca >>>>> http://www.sandelman.ca/ | ruby on rails [ >>>>> >>>>> >>>>> -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman >>>>> Software Works -= IPv6 IoT consulting =- >>>>> >>>>> >>>>> >>>> >>>> -- PGP key change time for me. New-ID 7B172BEA; old-ID >>>> 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. >>>> Sorry if that mucks something up;-) >>>> <0x7B172BEA.asc>_______________________________________________ >>>> homenet mailing list homenet@ietf.org >>>> <mailto:homenet@ietf.org> <mailto:homenet@ietf.org >>>> <mailto:homenet@ietf.org>> >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> <https://www.ietf.org/mailman/listinfo/homenet> >>>> <https://www.ietf.org/mailman/listinfo/homenet >>>> <https://www.ietf.org/mailman/listinfo/homenet>> >>> >>> >>> >>> _______________________________________________ homenet mailing >>> list homenet@ietf.org <mailto:homenet@ietf.org> >>> https://www.ietf.org/mailman/listinfo/homenet >>> <https://www.ietf.org/mailman/listinfo/homenet> >>> >> >> -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 >> expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that >> mucks something up;-) <0x7B172BEA.asc> > > -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-)
0x7B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
