Re: [homenet] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Are you assuming here there's a central Homenet controller that presents
> a web interface where the "house owner" can choose which names get
> published?

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

> I'm probably missing something, Michael, so please explain if you agree
> with the analysis above, whether you're assuming a central controller,
> and, if so, where is the central controller located in a network that has
> multiple edge routers.

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

--
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] securing zone transfer

[Juliusz Chroboczek]

>> Your turn now.  Could you please describe the UI that you envision?

> The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
> is presented to the house owner, they click on the ones that the want to
> be publically visible.

Are you assuming here there's a central Homenet controller that presents
a web interface where the "house owner" can choose which names get
published?

Daniel's original draft used the term "CPE" for the hidden primary.  At
the time, I pointed out two things:

  - there's no single CPE in Homenet, there's zero, one or more edge
routers which might or might not be ISP-controlled devices;
  - no Homenet service should be bound to an ISP-controlled device.

I believe that these requirements still reflect WG consensus.

Assuming that I'm right, I can only see two ways to provide global naming
without giving up on the properties above:

  - we avoid relying on a central controller (hidden primary with web
interface);
  - we define a way to elect the central controller (hidden primary)
in a way that doesn't bind the election to an ISP-controlled device.

(Am I missing a third option?)

The protocol that I have outlined is certainly not perfect, but it has the
virtue of avoiding the need for a central controller in the Homenet by
outsourcing naming using an end-to-end protocol between the host being
named and an external DNS primary.

I'm probably missing something, Michael, so please explain if you agree
with the analysis above, whether you're assuming a central controller,
and, if so, where is the central controller located in a network that has
multiple edge routers.

-- Juliusz

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

Re: [homenet] securing zone transfer

[Juliusz Chroboczek]

> It would seem your objection can be summarized as "we don't need this". 
> Correct me if I'm wrong.

No, my objection is that I cannot see how that can work in a decentralised
manner -- with no central Homenet controller.

> To me is like saying we don't need a new routing protocol like BABEL, because 
> we have loads of routing protocols already.
> [for the record I strongly supported incorporating BABEL into Homenet, 
> because to me it was the best choice]

When we argued between Babel and IS-IS, we were deciding between two
decentralised protocols.  In some sense, we were having an argument among
friends -- had someone suggested we use a central SDN controller instead
of a distributed routing protocol, we'd probably have ganged on the culprit.

If that's okay, I'll give a more detailed description of my objection as
a followup to MCR's comment, since the two of you are saying very roughly
the same thing.

-- Juliusz

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

Re: [homenet] webauthn for routers

[Michael Thomas]

On 6/12/19 3:18 PM, Michael Richardson wrote:

Michael Thomas  wrote:
 >> Secondary admins are encouraged to guard against loss/destruction of 
mobile
 >> phone, and it is also possible to enroll a second time, provided the
 >> manufacturer agrees (this is both a feature and a bug)
 >>
 >> The code is at https://github.com/CIRALabs/
 >>

 > I'm not sure we're talking about the same thing? I'm just talking about 
the
 > normal web interface that home routers have to hand configure them. 
There's
 > no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.
Oh, sorry, I wasn't thinking about TLS. Obviously you need server certs 
for that. I was thinking about the client side authentication which is 
what webauthn is for, and it doesn't require certs of any kind, iirc.


 > I wrote a blog post which considered the enrollment problem of a
 > webauthn-like protocol (way before webauthn was even started). I'm not 
sure
 > if it works for the special case of a home router though.

 > 
http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

 > Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

Thanks, it's probably pretty dated by now, especially all of the crypto 
hackery :). The thing that I'm not sure about is whether the out-of-band 
method for adding clients would work in a home router situation. My 
solution required the server (ie, the router) to send email to somebody. 
It could be sms too, but it's not very clear that email from a naked 
router ip address would be very effective since, like, nobody accepts 
email from home net ranges. I guess in theory you could configure an 
mail account for the router, but that seems sort of like a non-starter. 
But there may be other ways to finesse this.


Mike


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

Re: [homenet] webauthn for routers

[Michael Richardson]

Michael Thomas  wrote:
>> Secondary admins are encouraged to guard against loss/destruction of 
mobile
>> phone, and it is also possible to enroll a second time, provided the
>> manufacturer agrees (this is both a feature and a bug)
>>
>> The code is at https://github.com/CIRALabs/
>>

> I'm not sure we're talking about the same thing? I'm just talking about 
the
> normal web interface that home routers have to hand configure them. 
There's
> no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.

> I wrote a blog post which considered the enrollment problem of a
> webauthn-like protocol (way before webauthn was even started). I'm not 
sure
> if it works for the special case of a home router though.

> 
http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

> Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

--
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] webauthn for routers

[Michael Thomas]

On 6/12/19 12:13 PM, Michael Richardson wrote:

MIchael Thomas  wrote:
 >>> There are no passwords.

 >> Yes please.

 > Speaking of which, should we be encouraging router vendors to implement
 > webauthn? Considering that probably half of home routers have the default
 > password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/



I'm not sure we're talking about the same thing? I'm just talking about 
the normal web interface that home routers have to hand configure them. 
There's no need for certs at all.


I wrote a blog post which considered the enrollment problem of a 
webauthn-like protocol (way before webauthn was even started). I'm not 
sure if it works for the special case of a home router though.


http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

Enrollment, of course, is out of scope for webauthn, per se.

Mike

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

Re: [homenet] webauthn for routers (was: securing zone transfer)

[Michael Richardson]

MIchael Thomas  wrote:
>>> There are no passwords.

>> Yes please.

> Speaking of which, should we be encouraging router vendors to implement
> webauthn? Considering that probably half of home routers have the default
> password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/


--
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] webauthn for routers (was: securing zone transfer)

[MIchael Thomas]

On 6/12/19 7:42 AM, Ted Lemon wrote:
On Jun 12, 2019, at 10:22 AM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

There are no passwords.


Yes please.


Speaking of which, should we be encouraging router vendors to implement 
webauthn? Considering that probably half of home routers have the 
default password, that seems like it would be a Good Thing.


I do wonder what the implications are for enrollment.

Mike

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

Re: [homenet] securing zone transfer

[Ted Lemon]

On Jun 12, 2019, at 10:22 AM, Michael Richardson  wrote:
> There are no passwords.

Yes please.

Juliusz, what you are saying is what you said to me when I did the original 
homenet naming architecture, which you said was too heavyweight.  There seemed 
to be consensus in the room for dropping this, and so we did.   But as time has 
gone by, it’s become more and more clear to me that even though this use case 
does not apply to every device in the home, it is a use case that applies in a 
significant number of cases.

We can of course build this from ad-hoc, non-standardized tools like dyndns.   
We can insist that anyone who wants to address this use case has to either be a 
security expert, or be vulnerable.   Or we can figure out a clean way to do it 
using the building blocks we already have: HNCP, DNS Update, DHCP PD, etc.   
And then we can write a standard that describes how to do that, and see how 
much uptake it gets in the real world.

I would also like to point out that in addition to Ray’s point about DANE, 
being able to publish an external name means that you can get a cert from Lets 
Encrypt.   And _that_ means that we can close the frustrating gap that we have 
now with home network security, which is that the web UI isn’t secure.   And we 
can do this with any browser, not just with browsers that support TLSA (which, 
unfortunately, are rare as hen’s teeth).

I’d like to also point out that one of your objections was that implementing 
something like the Service Registration Protocol would be too hard, and too 
heavy.  It turns out to fit into 12k of code space in a constrained device 
operating over 802.15.4.   The SRP proxy is a bit larger, but quite reasonable. 
  The code for both is on the hackathon github repo, and is under active 
development (but works at present):

https://github.com/IETF-Hackathon/mDNSResponder 


The README file only talks about the Discovery Proxy, but the 
ServiceRegistration subdirectory contains a complete simple service 
registration client: srp-simple.c
It also includes a registration proxy: srp-gw.c

Getting the SRP gateway to talk to a front-end naming primary would be very 
simple.   Getting AXFR to work in either direction would be as well.   It’s 
just a service, after all.

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Your son clicks "publish name" in the Minecraft server's UI, at which
> point he faces the following dialog box:

> Domain: dyndns.minecraft.example.com
> Hostname: minecraft-7ac8
> Password:

And where does the password come from?
If this is one he picks, how can I know that it's a good one?
And how do I prevent him from doing this?

> Your turn now.  Could you please describe the UI that you envision?

The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
is presented to the house owner, they click on the ones that the want to
be publically visible.  (They may also apply a security policy for access,
but that's not a naming issue)

There are no passwords.

--
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] securing zone transfer

[Ray Hunter (v6ops)]

Inline. Long post.

Juliusz Chroboczek wrote on 12/06/2019 04:03:

Actually, it's fatal, because you can't get a certificate for "boombox.local"
so you can't secure it that way.  So you always have to use the FQDN.

That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names that
only appear in local MDNS.

No. They are directly related. See below.

I think that's our main disagreement.
For some reason, you guys seem to be assuming that the average user will
want to publish hundreds of names in the global DNS.

Hundreds?  How about two.
My son wants to publish his desktop's name so that his friend can reach his
system directly for minecraft.  I want the same.

Your son clicks "publish name" in the Minecraft server's UI, at which
point he faces the following dialog box:

   Domain: dyndns.minecraft.example.com
   Hostname: minecraft-7ac8
   Password:

The young man considers that default values are for noobz, and edits as
follows:

   Domain: richardson-family.vanity-dyndns.example.com
   Hostname: better-server-than-dads
   Password:

After the name is published (which takes half a second), the Minecraft UI
displays a "share" icon, so that your son can publish the server's name
over UUCP, or whatever it is that them youngsters use nowadays for chatting.

Your turn now.  Could you please describe the UI that you envision?

-- Juliusz


It would seem your objection can be summarized as "we don't need this". 
Correct me if I'm wrong.


To me is like saying we don't need a new routing protocol like BABEL, 
because we have loads of routing protocols already.
[for the record I strongly supported incorporating BABEL into Homenet, 
because to me it was the best choice]


Funnily enough my next door neighbor (who knows nothing about 
networking) could appreciate the use case.


He can currently control his central heating system from his smartphone. 
But he needs to pay for the rendezvous service, or has a tie in to a 
particular heating-system maintenance provider.


The use case would then be that an IoT device or local gateway device 
could use one common protocol (out of scope) to talk to the Homenet 
router, then the homenet router could publish and resolve names to 
backbone DNS infra, whilst the app developer wouldn't need the 
rendezvous service or NAT traversal. The rendezvous service is also a 
single point of attack for large scale DDOS, and also might raise 
privacy concerns because the manufacturer can monitor detailed use of 
all the devices they've sold. Mobile devices could use one single name 
to connect to the gateway device in a secure manner from anywhere.


So rather than being forced to use the manufacturer's thermostat, or 
sign a service contract from a particular maintenance provider tied to 
the manufacturer, he can use OpenTherm, and he can control OpenTherm 
from anywhere.


Yes, there are HTTP REST interfaces to accomplish this, but they ain't 
standard, and they ain't always easy to use.
[check out comments from people who've tried to automate this for 
multiple alternative REST-based providers]


Yes, each individual device could also manage names directly with 
multiple DNS outsourcing providers, but then you potentially create an 
explosion of keying and signing material if you want DNS-SEC to work in 
any meaningful way.


Especially as DNS is becoming more of a trust anchor for other services.

How much easier is it to trust devices using TLS over a self-signed 
certificate anchored via TLSA records to DANE on your own DNS zone?


accept TLS from any devices with certificates with CN 
*..homenet.com
accept TLS from any devices with certificates with CN 
*..homenet.com

deny all

Then the minecraft connection with your friend can be properly secured 
without resorting to chat protocols and shared secrets or IP filters.


You don't need to pay a CA for any magic beans because DANE will work 
with self-signed certificates, even in a chain (mode 2 trust anchor). 
And you can be sure no-one has messed with the certificate, because 
you've created the certificate yourself, and you've signed the DNS zone 
yourself with your own private keys that haven't been shared with anyone 
else. Sure, you still have to bootstrap all of this.


To me it seems obvious that people should be able to distribute services 
(if they want to) to their own network.
If they want to rely on the handful of technology giants for their 
security, then fair enough. But they should have a choice.


regards,
RayH



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


--
regards,
RayH

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

Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Thanks for the feedback.

> first, the gateway does not know for sure which external NS are use 
by the secondary DNS service,


Agreed. The draft needs to address how the service is boot-strapped and 
auto-configred.


> second the IPs of the WAN port might not be the internet facing IPs 
and this could break inbound connectivity


I hope that we're going to be able to move past IP filtering as the 
primary security mechanism for this draft.


Especially in the presence of renumbering.

regards,

Jacques Latour wrote on 11/06/2019 20:59:


Daniel,

In trying to setup our secure home gateway project to have the 
external zone & primary DNS server setup and managed on the gateway 
itself and to XFR back to secondary name servers somewhere turned out 
not be functional or practical, first, the gateway does not know for 
sure which external NS are use by the secondary DNS service, second, 
the IPs of the WAN port might not be the internet facing IPs and this 
could break inbound connectivity.  We’re looking at using dynamic DNS 
updates for things that need internet connectivity, and have the 
primary DNS server on the main land.   TSIG & DNS over TLS look like a 
good option to look at.


Jacques

*From:*homenet  *On Behalf Of *Daniel Migault
*Sent:* June 7, 2019 4:03 PM
*To:* homenet 
*Subject:* [EXT] [homenet] securing zone transfer

Hi,

The front end naming architecture uses a primary and a secondary dns 
server to synchronize a zone. The expected exchanges are (SOA, NOTIFY, 
IXFR, AXFR. We would like to get feed backs from the working group on 
what are the most appropriated way to secure this channel.


Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not 
provide confidentiality, and we would rather go for user space 
security.  Are there any recommendation for using TLS or DTLS in that 
case ?


Any thoughts would be helpful.

Yours,

Daniel



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


--
regards,
RayH

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