Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
> OK. So I think the comparison with me and my printer is probably a red
> herring. :)

A bit, yes.
The part where it's not, is that having established this out of band
process (when the discovery was authorized),  a secured channel remains, in
which one can exchange credentials for next time.  It's not TOFU.
It's more like, "Trust After First Discovery" or something like that.

> What I was getting at when talking about Christian's work is that the 
process
> of validating the initial leap of faith for homenet could be similar to 
the
> process that Christian is using for validating the pairing process in 
private
> service discovery.

I agree, exactly.  That's the laudry list of processes.


--
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] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

OK.   So I think the comparison with me and my printer is probably a red
herring. :)

What I was getting at when talking about Christian's work is that the
process of validating the initial leap of faith for homenet could be
similar to the process that Christian is using for validating the pairing
process in private service discovery.

On Tue, Aug 1, 2017 at 8:42 PM, Michael Richardson 
wrote:

>
> Ted Lemon  wrote:
> > So what you're saying is ephemeral is the keying used for the initial
> > exchange?
>
> yes, it's probably more about authenticating the initial (DH/TLS/etc.)
> exchange.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
> So what you're saying is ephemeral is the keying used for the initial
> exchange?

yes, it's probably more about authenticating the initial (DH/TLS/etc.) exchange.

--
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] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

So what you're saying is ephemeral is the keying used for the initial
exchange?

On Tue, Aug 1, 2017 at 4:48 PM, Michael Richardson 
wrote:

>
> Ted Lemon  wrote:
> > You agree that it's a different problem right?
>
> mcr> The common part is that one might have a similar set of external
> mcr> (physical) signals.
>
> mcr> Should Dave bring his printer to the IETF network, and they
> happen to
> mcr> discovery each other via privacy-enhanced dnssd magic (cf: Arthur
> Clark's
> mcr> definition of magic), then it would be good that they can prove
> that it's
> mcr> really them.
>
> > To be honest, I probably missed the point you were making—I just
> went back
> > and reviewed this exchange, and I don't actually understand what the
> > distinction is that you are making between ephemeral and long-lived
> > relationships.
>
> This thread started by being about the problem of getting devices in the
> home
> to securely join the homenet.  One sees a list of possible routers in the
> home, and identifies one that should belong, and tells your homenet that it
> should be allowed to join.  (And the router also is told to join your
> network).
>
> The short-term exchange is where you discover the new router and do the
> out-of-band secured exchange to establish initial trust.  Within that
> initial
> trust, longer-term credentials (asymmetric keys) are exchanged.
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
> You agree that it's a different problem right?

mcr> The common part is that one might have a similar set of external
mcr> (physical) signals.

mcr> Should Dave bring his printer to the IETF network, and they happen to
mcr> discovery each other via privacy-enhanced dnssd magic (cf: Arthur 
Clark's
mcr> definition of magic), then it would be good that they can prove that 
it's
mcr> really them.

> To be honest, I probably missed the point you were making—I just went back
> and reviewed this exchange, and I don't actually understand what the
> distinction is that you are making between ephemeral and long-lived
> relationships.

This thread started by being about the problem of getting devices in the home
to securely join the homenet.  One sees a list of possible routers in the
home, and identifies one that should belong, and tells your homenet that it
should be allowed to join.  (And the router also is told to join your
network).

The short-term exchange is where you discover the new router and do the
out-of-band secured exchange to establish initial trust.  Within that initial
trust, longer-term credentials (asymmetric keys) are exchanged.


--
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] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

On Aug 1, 2017, at 11:38 AM, Michael Richardson  wrote:
> You agree that it's a different problem right?
> 
> The common part is that one might have a similar set of external (physical) 
> signals.
> 
> Should Dave bring his printer to the IETF network, and they happen to
> discovery each other via privacy-enhanced dnssd magic (cf: Arthur Clark's
> definition of magic), then it would be good that they can prove that it's 
> really them.

To be honest, I probably missed the point you were making—I just went back and 
reviewed this exchange, and I don't actually understand what the distinction is 
that you are making between ephemeral and long-lived relationships.

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

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

On Jul 31, 2017, at 8:20 PM, Michael Richardson  wrote:
>  a) do they really want this kind of traffic?
>  b) the certs issued will go into their cert transparency list, and I think
> that means we lose privacy.
>  c) to make it work, they have to verify things.  IPv6 makes the
> connectivity easy to arrange, but it seems like it's a big exposure for
> the device.  We are talking more than just routers... I'm thinking
> printers and all sorts of things.

Probably they don't, although they appear to be handling rather a lot of 
traffic already.   The problem is, we have no way to establish trust on a 
domain name because the browser vendors don't support DNSSEC-based TLS certs.   
For some reason.   Not that I am bitter...

> It doesn't establish initial trust, it gives the user a trusted icon in their
> browser once we have initial trust.

Blrk.   I just don't think it's a good idea to burn certs into routers.   And I 
don't want the end user to be relying on their router vendor for their PKI.   
But I will admit that I haven't done a thorough threat analysis, so I can't 
justify my collywobbles.

>The Pledge can choose to accept vouchers using less secure methods.
>These methods enable offline and emergency (touch based) deployment
>use cases:

That ain't going to work.   But we can probably figure something out.

> Christian's comments in DNSSD (which I also watched today) is right though:
> for many applications in *discovery* is important you probably don't want
> certs, because they reveal too much, and the relationship is too ephermeral.
> The link between Dave's Laptop and Dave's Cool Printer is probably longer.

Indeed, but we don't want Dave's Laptop going around asking for Dave's Cool 
Printer when Dave's Laptop is not on the home network where Dave's Cool Printer 
lives.


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

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
> That partly gets rid of the security exception on each access to the
> web interface: provided the web browser loads the new trust anchor.


> I don't know how to make that work without a fake domain tree. Can't we 
just
> use ACME+letsencrypt.org?

I hadn't thought about that.
The objections I can think about involves three kinds of things:
  a) do they really want this kind of traffic?
  b) the certs issued will go into their cert transparency list, and I think
 that means we lose privacy.
  c) to make it work, they have to verify things.  IPv6 makes the
 connectivity easy to arrange, but it seems like it's a big exposure for
 the device.  We are talking more than just routers... I'm thinking
 printers and all sorts of things.

> Sure. The question is, what value does the PKI cert add here? I agree that
> having a cert that validates is good for the web UI, but I don't see how 
it
> helps in establishing trust.

It doesn't establish initial trust, it gives the user a trusted icon in their
browser once we have initial trust.

> I would be tempted to do something like what Christian is doing with DNSSD
> privacy: print a QR code on the box, take pictures of all the QR codes 
with
> your smartphone, and then use your smartphone app to bootstrap trust using
> those QR codes. You could do something similar by just flashing the front
> panel LEDs really fast when the "pair" button is pressed, and have the
> smartphone decode that, as is being done with exfiltration malware now. I
> suspect there's code we could download... :)

I think that these are all really good ways to establish initial trust.
BRSKI mentions the whole category at:
  
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-4.2

  3.  The Pledge MAY have an operational mode where it skips Voucher
  validation one time.  For example if a physical button is
  depressed during the bootstrapping operation.  This can be
  useful if the vendor service is unavailable.  This behavior SHOULD be
  available via local configuration or physical presence methods to
  ensure new entities can always be deployed even when autonomic
  methods fail.  This allows for unsecured imprint.

Christian's comments in DNSSD (which I also watched today) is right though:
for many applications in *discovery* is important you probably don't want
certs, because they reveal too much, and the relationship is too ephermeral.
The link between Dave's Laptop and Dave's Cool Printer is probably longer.

--
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] Ted's security talk at IETF99: DNCP Security

[Stephen Farrell]

On 31/07/17 19:00, Ted Lemon wrote:
> I don't know how to make that work without a fake domain tree.
> Can't we just use ACME+letsencrypt.org ?
I think the protocols would work fine, but I'm not sure there's
a current challenge type that'd work here, for LE or any similar
service. (The current set of challenges in the acme spec is at
[1].)

For my main home router (a Turris), I setup a VPN connection so
that the  for a name I control is routed to the Turris when
the VPN is up, and then I just used acme.sh [1] to talk to LE
and all that works just fine and gets rid of the annoying browser
insecurity warning when I use luci.

(I further cheat by only having that VPN up when I need to talk
to LE for renewal checks and otherwise just resolve the name
using 10/8 inside the home, but I'm sure there're better options.)

So the plumbing/protocols all do work if you have a name and
address that works from the CA service provider POV. It's just
that almost nobody can do that today.

Is this something where it'd be worth trying to get a few folks
from the various communities on a call to see if we can come up
with something that might work for the openwrt/lede type cases?

If so, I'd be happy to try set that up in a month or so, when
holliers are done and I'm supposedly gonna be a chair-like being:-)
I'd be happy to try that even if the chances of a Eureka! moment
aren't very high. (And btw, the reason I suggest that scope is
that I figure commercial device vendors can figure out the cert
issuance part just fine already, and with better assurance, but
probably have the same issues with browser trust stores as do the
openwrt/lede folks, so I'm not suggesting excluding commercial
device vendors, just limiting the scope to stuff that could be
worked on today by anyone if we did have that Eureka! moment.)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-8
[2] https://github.com/Neilpang/acme.sh



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

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
mcr> Is there a document for this Ted? I will offer to help.

> Your help would be much appreciated, but I don't know why there would
> be an election, so there's at a minimum some thinking to do
> there. There is no document yet.

I think that we need to have a Registrar that issues certificates.
ANIMA's BRSKI document automates much of this.

That partly gets rid of the security exception on each access to the
web interface: provided the web browser loads the new trust anchor.

> Also, bear in mind that a vendor-centric approach to this probably isn't
> going to work, because right now all the Homenet work I'm aware of is
> happening on OpenWRT and LEDE. I'm sure that will change if we come up

This is where all the other pairing mechanisms come into play.
You mentioned having a laundry list of them.

--
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] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

On Jul 31, 2017, at 11:21 AM, Michael Richardson  wrote:
> The things that Ted wants, such "this the ID of the router", and the like,
> and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
> to work in Homenet, provided that HNCP can elect a registrar.
> I think that is entirely workable, btw.
> I don't think that Homenet has to invent any protocols here.
> 
> Is there a document for this Ted?  I will offer to help.

Your help would be much appreciated, but I don't know why there would be an 
election, so there's at a minimum some thinking to do there.   There is no 
document yet.

Also, bear in mind that a vendor-centric approach to this probably isn't going 
to work, because right now all the Homenet work I'm aware of is happening on 
OpenWRT and LEDE.   I'm sure that will change if we come up with something 
vendors want to deploy, but it has to work for the prototype case too.   And 
there's no particular reason to think that a PKI key from a vendor makes a 
device trustworthy.

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

[homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

So I'm watching via meetecho the meeting.  Some minor comment that it seems
like many things have happened in homenet that haven't really been on the
list.  {Or maybe it was just DMARC vs ietf.org forwarding "helping" me. I've
had to whitelist the ietf.org mail servers}

The things that Ted wants, such "this the ID of the router", and the like,
and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
to work in Homenet, provided that HNCP can elect a registrar.
I think that is entirely workable, btw.
I don't think that Homenet has to invent any protocols here.

Is there a document for this Ted?  I will offer to help.

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