Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 19:21, Michael Richardson wrote:
> 
> Stephen Farrell  wrote:
> > 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.
> 
> If you are suggesting we should write a clear problem statement with
> new-fangled and terminology devoid of historical baggage, and then argue
> about that for 6-10 months... well...  we could start that now :-)

You are entirely correct that I'm not suggesting that:-)

> Two routers exchanging some keys on a TOFU basis might qualify as (mutual)
> enrollment, as the keys are stored someplace for the "second use".

Sure. OTOH, using the term enrollment I think might confuse
folks and perhaps the discussion as there's quite a bit of
(mostly PKI;-) baggage associated with that term, for me anyway.

Aside from terminology the main thing is the distinction between
situations that do, or do not, involve a party external to the
homenet, which makes a very big difference.

Cheers,
S.

> 
> Stephen Farrell  wrote:
> > 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
> 
> the reason I said that things should be finished, is because I believe that a
> 3/4 year problem statement discussion will distract the WG from actually
> finishing that existing work
> 
> --
> Michael Richardson , 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
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Michael Richardson]

Stephen Farrell  wrote:
> 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.

If you are suggesting we should write a clear problem statement with
new-fangled and terminology devoid of historical baggage, and then argue
about that for 6-10 months... well...  we could start that now :-)

Two routers exchanging some keys on a TOFU basis might qualify as (mutual)
enrollment, as the keys are stored someplace for the "second use".

Stephen Farrell  wrote:
> 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

the reason I said that things should be finished, is because I believe that a
3/4 year problem statement discussion will distract the WG from actually
finishing that existing work.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Michael Richardson]

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). I think
> it might be worth having someone give a presentation on the anima
> enrollment model, if someone is willing to do that.

Say the word... we got lots of slides.
I even assembled a pekka chukka talk last year and rehearsed it, but decided
not to present it due to family obligations at the Seoul IETF.

.. how does Google Home enrollment work?
{I wonder if someone has done a survey paper on the various different
vendor's mechanisms}

I have a chromecast "enrolled", and it "works" because I have a really smart
device (my phone) which already has credentials, and because my chromecast
has 10million pixels on my TV to talk to me.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Juliusz Chroboczek]

> 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),

I'm not worried about Babel.  I am worried about HNCP, since I fear
there's nobody who's both able and willing to work on HNCP extensions for
security.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Ted Lemon]

On Jan 24, 2018, at 10:39 AM, Stephen Farrell  wrote:
> 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.

I think this is a valid point.   We've talked about it as a trust establishment 
ritual; we could also call it "pairing" or "association" or "joining."

However, I think that there is some value in having a "third party" in the form 
of a phone or computer that is in charge.   This is how Google does it, and it 
appears to be a pretty good method.   I don't know how widely successful it's 
been—there were a lot of unsold Google Homes on the shelf right before 
Christmas—but it's at least working for the early adopters.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

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
>>  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 
  wrote:
 
 
 Hiya,
 
 On 24/01/18 13:32, Michael Richardson wrote:
> 
> Stephen Farrell  wrote:
>> On 24/01/18 02:48, Michael Richardson wrote:
>>> 
>>> Stephen Farrell  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 , Sandelman
> Software Works -= IPv6 IoT consulting =-
> 
> 

Re: [homenet] security work items - what do we want to do?

[Ted Lemon]

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

> On Jan 24, 2018, at 10:03 AM, Stephen Farrell  
> 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
>>>  wrote:
>>> 
>>> 
>>> Hiya,
>>> 
>>> On 24/01/18 13:32, Michael Richardson wrote:
 
 Stephen Farrell  wrote:
> On 24/01/18 02:48, Michael Richardson wrote:
>> 
>> Stephen Farrell  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 , 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  
>>> > 
>>> https://www.ietf.org/mailman/listinfo/homenet 
>>> 
>>> >> >
>> 
>> 
>> 
>> ___ homenet mailing list 
>> homenet@ietf.org  
>> 

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

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
>>  wrote:
>> 
>> 
>> Hiya,
>> 
>> On 24/01/18 13:32, Michael Richardson wrote:
>>> 
>>> Stephen Farrell  wrote:
 On 24/01/18 02:48, Michael Richardson wrote:
> 
> Stephen Farrell  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 , 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  
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> 
> 
> 
> ___ homenet mailing list 
> homenet@ietf.org 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
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 13:32, Michael Richardson wrote:
> 
> Stephen Farrell  wrote:
> > On 24/01/18 02:48, Michael Richardson wrote:
> >>
> >> Stephen Farrell  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 , 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
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Michael Richardson]

Stephen Farrell  wrote:
> On 24/01/18 02:48, Michael Richardson wrote:
>>
>> Stephen Farrell  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.

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

--
]   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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 02:48, Michael Richardson wrote:
> 
> Stephen Farrell  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?

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

Cheers,
S.

> I think I've missed the last three homenet WG sessions due to conflicts.
> I find that the ML is too frequently ratholed when it isn't silent.
> 
> > - Does the homenet wg need to profile use of those
> > security mechanisms, for example to document a way to
> > establish initial keying material that we'd like to see
> > implemented when those protocols are used in home networks?
> 
> > - If so, (and without yet getting into discussions about ToFU
> > etc) do we have people who are interested in working on
> > that?
> 
> Yes, but not yet.
> 
> --
> Michael Richardson , 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
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet