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

[Stephen Farrell]

Hi All,

Barbara and I chatted about the discussion in this thread,
and here's our summary, please correct us if we've gotten
stuff wrong.

- On item 1, work on the security considerations of
draft-ietf-homenet-simple-naming will proceed as usual.

- On item 2, (the perimeter security draft milestone in
our charter), we don't see anyone stepping up right now
to do that work, so unless someone does in the next few
days, we'll have a chat with our AD about whether or not
it makes sense to remove that milestone from the charter,
or do something else. We'll report back on that at
IETF-101 or before.

- On item 3, (profiling HNCP and Babel security stuff
for homenet), it seems like folks would like to wait a
bit and see how at least the Babel work progresses, and
maybe we should have a discussion at IETF-101 about when
it makes sense to start work on profiling what gets picked
in the Babel WG, for use in homenets, and whether there's
any chance of near-term progress on HNCP security
mechanisms for homenets. We'll also allocate a slot in
our draft agenda for a presentation about anima enrolment
(as offered by Michael Richardson, assuming he's still up
for doing that:-) to provide some additional background
for that discussion.

Again, thanks for the discussion so far, and please
do correct the above if we've mis-interpreted the
sense of the list.

Cheers,
Barbara and Stephen.


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?

[Juliusz Chroboczek]

>  the AmazonEcho/GoogleHome/Mycroft/etc. devices seem like ideal platforms
>  to be the root of a secure network.

Huh?

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

[Michael Richardson]

Andrew Sullivan  wrote:
>> On 24/01/18 13:32, Michael Richardson wrote:
>> >
>> > b) DNS naming and delegation in Last Call.

> All of it, or just the simple one?  I think the timeframe for "simple"
> is "soonish" and the "real" one from the architecture document might
> well be "heat death of the universe".  Also, I think the "real" one is
> going to interact badly with a number of security issues, so I am not
> too convinced that we will be able to do the "real" one without
> working some on the use cases.

I think it's sufficient for the WG to think that we got something done, and
if we split up the work and defer it, then fine.  If we need security work to
make the more "real" one work right, then that's good *input* to the security
work, and we could have an ID with an empty section that waits for awhile,
but we have otherwise reached WG consensus on.

>> Reasonable points. Do others (dis)agree?

> Only a little:

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

> I disagree to the extent I agree with the above.  That is, I think it
> is reasonable to work on things as it starts to be clear what else we
> can rely on.

It sounds like we should write a security "results" document.
This would be a kind of requirement document on the security work, but more
to the point, it would detail what other work could depend upon.



{ps: the AmazonEcho/GoogleHome/Mycroft/etc. devices seem like ideal platforms
 to be the root of a secure network. I suspect that there are boostrap
 issues with the ones that do all the processing in the cloud}

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

[Andrew Sullivan]

On Wed, Jan 24, 2018 at 01:51:08PM +, Stephen Farrell wrote:

> On 24/01/18 13:32, Michael Richardson wrote:
> > 
> > b) DNS naming and delegation in Last Call.

All of it, or just the simple one?  I think the timeframe for "simple"
is "soonish" and the "real" one from the architecture document might
well be "heat death of the universe".  Also, I think the "real" one is
going to interact badly with a number of security issues, so I am not
too convinced that we will be able to do the "real" one without
working some on the use cases.

> Reasonable points. Do others (dis)agree?

Only a little:

> 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

I disagree to the extent I agree with the above.  That is, I think it
is reasonable to work on things as it starts to be clear what else we
can rely on.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

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

[Michael Richardson]

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.

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





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

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

[Stephen Farrell]

Hi homenet folks,

Barbara and I were chatting about the security work that
may need to be done in the homenet wg in the coming months
and here are our thoughts on that. We'd like to get folks'
reactions to those:

- Does this sound roughly right or off the wall?
- If the former, do we think it's doable?
- If so, who'd like to help do the work etc.

It seems there are three possible work items for us
to consider:

1. Documenting the security considerations and any
security mechanisms needed for draft-ietf-homenet-simple-naming.
We assume that that work will be done as a normal part
of developing that draft, so is, or will be, in-hand.

2. We have this milestone in our charter:

"Nov 2018 - Submission of the perimeter security draft
 to the IESG as Informational RFC"

- Do we still agree that this is a good milestone?
- If not, why not?
- If so, do we have people who are willing to work on
  this?

3. HNCP and Babel define some security mechanisms that can
be used to secure those protocols, and more work is being
done at the moment in the babel WG on uses of HMAC and DTLS
with Babel.

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

If possible, it'd be great to get a sense of the WG's
ideas on the above before we construct an agenda for
our meeting in London in March (which is not that far
away now).

Thanks,
Barbara & Stephen



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