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

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jan 2018 22:46:01 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jan 2018 21:48:23 -0500

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

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

    > etc) do we have people who are interested in working on

Yes, but not yet.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jan 2018 08:23:07 +0000

Hiya,

> future.  Some kind of BCP on interactions with MUD, SUIT, etc. IN THE

Can you say more? Eg. what would be needed before you think
it'd be sensible for homenet to start work in this space?

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jan 2018 08:32:58 -0500

Stephen Farrell <[email-masked]> wrote:
    >> Stephen Farrell <[email-masked]> 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.

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

    > volunteered in the past before I was helping out as chair (if so,

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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jan 2018 13:51:08 +0000

Hiya,

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jan 2018 09:55:39 -0500

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.

> On Jan 24, 2018, at 8:51 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x7B172BEA.asc>_______________________________________________
> homenet mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jan 2018 15:03:27 +0000

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.

>>>>> Stephen Farrell <[email-masked]> 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.
>>> 
>>> a) finish (really finish) Babel work, that might mean interacting
>>> with BABEL WG
>>> 
>>> c) ANIMA and related groups publish *managed* enrollment, so that
>>> HOMENET can consider how *unmanaged* enrollment might work.
>> 
>> 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.
>> 
>>> 
>>>> 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/
>>>
>>> 
>> 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  [ ]     [email-masked]
>>> http://www.sandelman.ca/        |   ruby on rails    [
>>> 
>>> 
>>> -- Michael Richardson <[email-masked]>, 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;-) 
>> homenet mailing list [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/homenet
>> <https://www.ietf.org/mailman/listinfo/homenet>
> 
> 
> 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jan 2018 10:36:39 -0500

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 <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>>> homenet mailing list [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
>>> <https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>>
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>
>> 
> 
> -- 
> <0x7B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jan 2018 15:39:37 +0000

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.

>>> 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.
>> 
>> 
>>> 
>>>>>>> Stephen Farrell <[email-masked]> 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
>>>>> 
>>>>> c) ANIMA and related groups publish *managed* enrollment, so
>>>>> that HOMENET can consider how *unmanaged* enrollment might
>>>>> work.
>>>> 
>>>> 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.
>>>> 
>>>>> 
>>>>>> 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: 
>>>> 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  [ ]     [email-masked] 
>>>>> -- Michael Richardson <[email-masked]>, 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.
>>>>  homenet mailing list [email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]
>>>> <mailto:[email-masked]>> 
>>>> <https://www.ietf.org/mailman/listinfo/homenet
>>>> <https://www.ietf.org/mailman/listinfo/homenet>>
>>> 
>>> 
>>> 
>>> _______________________________________________ homenet mailing
>>> list [email-masked] <mailto:[email-masked]>
>> mucks something up;-) <0x7B172BEA.asc>
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jan 2018 11:16:11 -0500

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 24 Jan 2018 18:43:58 +0100

> 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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jan 2018 14:16:23 -0500

Ted Lemon <[email-masked]> wrote:
    > 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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jan 2018 14:21:06 -0500

> and where there's no external party, such as google in the

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jan 2018 23:28:44 +0000

Hiya,

> about that for 6-10 months... well...  we could start that now :-)

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

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

> finishing that existing work
> 
> --

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jan 2018 18:57:43 -0500

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

> 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
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jan 2018 10:01:10 -0500

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

    > is reasonable to work on things as it starts to be clear what else we

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}

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 31 Jan 2018 20:53:48 +0100

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

Huh?

-- Juliusz