Re: [homenet] securing zone transfer

[Juliusz Chroboczek]

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

I see.  (I still disagree with the technical choices, especially that of
binding the domain with either the manufacturer or the ISP, but now I see
a little better where you're coming from.)

-- Juliusz

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

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Michael Richardson wrote on 13/06/2019 03:25:

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



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


Indeed this draft should say as little as possible about what should 
happen internally (whether there's one elected central Homenet 
controller for all ISP uplinks, or there's something running on all 
Homenet routers that updates an edge HNA per ISP uplink, or the HNA 
service runs on a host, or something else).


Probably the text isn't in that state yet.

The facts of life with using DNS are that:
- a zone delegation is built on a hierarchical name space with a single 
root;

- a delegated zone is a proper subset of a parent zone,
- zone signing occurs with one single active zone signing key signing 
the complete set of RR's in a zone (not a key or signature per RR), and 
where
- zone transfer updates are performed with a master/slave arrangement 
with a limited number of known peers per zone.


If you want individual hosts to interact directly with an outsourced 
name service based on DNS (instead of via an HNA), you either have to 
delegate the zone signing to the outsourced name service (which 
introduces a different trust model), or you assign a dedicated zone per 
host (possible?), or you introduce a massive key sharing and signing 
problem.





Another use case could be small companies who want to run something like 
Active Directory on premises (AD integrated DNS).


Then they could potentially build AD forest trust relationships between 
companies.


AD of course runs on a domain controller (DC). The DC function could 
then potentially take on the role of HNA, whether that is running a 
separate server or on a CPE.


--
regards,
RayH

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

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

[Juliusz Chroboczek]

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

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

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Thank you for your detailed reply.  I'm glad we're finally having
> a discussion about my objections to Daniel's proposal.

>> We strongly believe that the HNA needs to know the list of names in
>> order to be able to answer for those names when there is unstable (or
>> no) Internet connectivity.

>> Otherwise, applications and people have to know two different names for 
the
>> service. (A public one for when away, and the .local one)

> That's a good point.  While I happen to believe that it's reasonable to
> have a service known as "boombox.local" from home, and
> "boombox.jch.example.org" from the Internet, this might be inconvenient
> for e.g. smartphone users.

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.

>> o  the credentials for the dynamic DNS server need to be securely
>> transferred to the hosts that wish to use it.  This is not a
>> problem for a technical user to do with one or two hosts, but it
>> does not scale to multiple hosts and becomes a problem for non-
>> technical users.

> 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.  Yes, it's native IPv6 the
whole way, but they don't know that, and they don't have to know that.

> However, none of the end-user services that I know use incoming
> connections require a name in the global DNS to function (WebRTC, Skype,
> online games, BitTorrent, remote desktops, BTSync/Resilio, syncthing).

All of these are applications which either presently use cloud relays due to
NAT, or exchange IP addresses within the protocol.  All of these applications
are built during the IPv4 mindset of scarcity.

> Thus, my assumption is that the typical user will want to publish exactly
> 0 public names, and that only the extreme geek will publish up to 3 or 4
> (music server, NAS, game server, web server with family photographs).

> Richard, Daniel -- please be so kind as to explain why you think my
> assumption is wrong.  How many names do you envision wanting to publish in
> the public DNS, and for what purpose?

I think that you are living in the late 1990s IPv4 scarcity world.
The gigabit connected IPv6 home doesn't have to be like that.

I know at least twenty minor geeks who have music servers, NAS,
game server boxes and that family web server.  Yet, have no clue what
an IP address is.

Many of them have griped to me that there should be a way for them to easily
give their stuff names that they can access.  We've spoken at times of
building more mesh networks here, but what's the point if you can't give
things good names?

Anyway, you don't have to publish any names if you don't want to.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT 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] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
>> The front end naming architecture uses a primary and a secondary dns 
server to
>> synchronize a zone.

> People will recall that the need for a hidden primary hasn't been
> established yet.  Please see my unanswered e-mail of 21 November 2018.

> https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

We strongly believe that the HNA needs to know the list of names in order to
be able to answer for those names when there is unstable (or no) Internet 
connectivity.

Otherwise, applications and people have to know two different names for the
service. (A public one for when away, and the .local one)

In our current draft we have:

2.1.  Alternative solutions

   An alternative to having a single zone is what is currently common
   with IPv4, where a host uses a RESTful HTTP service to register a
   single name into a common public zone.  This is often called "Dynamic
   DNS", and there are a number of commercial providers, including
   dyn.com, ghandi.com.  These solutions were typically used by a host
   behind the CPE to make it's CPE IPv4 address visible, usually in
   order to enable incoming connections.

   For a small number (one to three) of hosts, use of such a system
   provides an alternative to the architecture described in this
   document.  The alternative does suffer from some limitations:

   o  the CPE/HNA router is unaware of the process, and can not answer
  for the same names when there are disruptions in connectivity.
  This makes the home user using different names when there are
  disruptions.

   o  the CPE/HNA router can not control the process.  Any host can do
  this regardless of whether or not the home network administrator
  wants the name published or not.  There is therefore no possible
  audit trail.

   o  the credentials for the dynamic DNS server need to be securely
  transferred to the hosts that wish to use it.  This is not a
  problem for a technical user to do with one or two hosts, but it
  does not scale to multiple hosts and becomes a problem for non-
  technical users.

   o  "all the good names are taken" - current services put everyone's
  names into a some set of zones, and there are often conflicts.
  Distinguishing similar names by delegation of zones was among the
  primary design goals of the DNS system.

   There is no technical reason why a RESTful cloud service could not
   provide solutions to many of these problems, but this document
   describes a DNS based solution.

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

> The front end naming architecture uses a primary and a secondary dns server to
> synchronize a zone.

People will recall that the need for a hidden primary hasn't been
established yet.  Please see my unanswered e-mail of 21 November 2018.

  https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

-- Juliusz

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

Re: [homenet] securing zone transfer

[Mark Andrews]

> On 10 Jun 2019, at 11:27 pm, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>> For dns updates, SIG(0) works fine. I have code you can steal that
>> works with mbedtls and ecdsa. Signing and validation.  But I think TLS
>> client certs can also work.  Proving the front end servers identity
>> sounds like the hard part.
> 
> Just to ask again clearly:
> 
> 1a) is it possible to authorize an AXFR transfer by SIG(0)?

Yes.

> 1b) is it possible to authorize an SOA query by SIG(0)?

Yes.

> 2) is anyone doing AXFR over TLS  (DPRIVE)?
> 
> {3) is RFC3007 really the most recent text on dynamic DNS?}

What has changed to need a more recent RFC?  Once you can identify the
requesting party, which SIG(0) and TSIG can do, the rest is policy.

I suppose we could have DHCP clients send KEY rdata as part of the DHCP
request for DHCP servers to insert in the reverse zone when addresses /
prefixes are allocated to allow the clients to use SIG(0) UPDATE requests
to update reverse zones.  This would allow for more than PTR records to
be added to reverse zones.  I did write a I-D about this for PD but got
no traction[1].  The technique would work equally well for individual addresses.
All it really requires is a DHCP code point to be allocated.

[1] https://datatracker.ietf.org/doc/draft-andrews-dnsop-pd-reverse/

>>> On Jun 8, 2019, at 6:32 PM, Michael Richardson  
>>> wrote:
>>> 
>>> 
>>> Ted Lemon  wrote:
> Can we use TLS for authorization, assuming that we have trusted
> certificates
> at both ends?  Perhaps this is more of a: did anyone implement this?
>>> 
 How is trust established?   Sure, doing TSIG over TLS is no problem.
>>> 
>>> Certificates are exchanged/created at manufacturing time (IDevID), and then
>>> optionally updated to LDevID.  The certificate contains the name of the zone
>>> which the HNA is authoritative for (or a control record pins the
>>> certificate).
>>> 
>>> TSIG requires a shared secret, thus a database of shared secrets available
>>> online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
>>> if I have to use TSIG for mechanical reasons, I want to derive the secret
>>> From the TLS.
>>> 
>>> I need to authorize the following:
>>> 1) DNS update of some data (NS, DS,  that NS points to) by
>>> Distribution Master (cloud/public system)
>>> 2) SOA query by Distribution Master by HNA.
>>> 3) AXFR by Distribution Master by HNA.
>>> 
>>> --
>>> Michael Richardson , Sandelman Software Works
>>> -= IPv6 IoT consulting =-
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
> For dns updates, SIG(0) works fine. I have code you can steal that
> works with mbedtls and ecdsa. Signing and validation.  But I think TLS
> client certs can also work.  Proving the front end servers identity
> sounds like the hard part.

Just to ask again clearly:

1a) is it possible to authorize an AXFR transfer by SIG(0)?
1b) is it possible to authorize an SOA query by SIG(0)?
2) is anyone doing AXFR over TLS  (DPRIVE)?

{3) is RFC3007 really the most recent text on dynamic DNS?}

>> On Jun 8, 2019, at 6:32 PM, Michael Richardson  
wrote:
>>
>>
>> Ted Lemon  wrote:
 Can we use TLS for authorization, assuming that we have trusted
 certificates
 at both ends?  Perhaps this is more of a: did anyone implement this?
>>
>>> How is trust established?   Sure, doing TSIG over TLS is no problem.
>>
>> Certificates are exchanged/created at manufacturing time (IDevID), and 
then
>> optionally updated to LDevID.  The certificate contains the name of the 
zone
>> which the HNA is authoritative for (or a control record pins the
>> certificate).
>>
>> TSIG requires a shared secret, thus a database of shared secrets 
available
>> online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
>> if I have to use TSIG for mechanical reasons, I want to derive the secret
>> From the TLS.
>>
>> I need to authorize the following:
>> 1) DNS update of some data (NS, DS,  that NS points to) by
>> Distribution Master (cloud/public system)
>> 2) SOA query by Distribution Master by HNA.
>> 3) AXFR by Distribution Master by HNA.
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-

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

[Ted Lemon]

For dns updates, SIG(0) works fine. I have code you can steal that works with 
mbedtls and ecdsa. Signing and validation.  But I think TLS client certs can 
also work.  Proving the front end servers identity sounds like the hard part. 

Sent from my iPhone

> On Jun 8, 2019, at 6:32 PM, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>>> Can we use TLS for authorization, assuming that we have trusted
>>> certificates
>>> at both ends?  Perhaps this is more of a: did anyone implement this?
> 
>> How is trust established?   Sure, doing TSIG over TLS is no problem.
> 
> Certificates are exchanged/created at manufacturing time (IDevID), and then
> optionally updated to LDevID.  The certificate contains the name of the zone
> which the HNA is authoritative for (or a control record pins the
> certificate).
> 
> TSIG requires a shared secret, thus a database of shared secrets available
> online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
> if I have to use TSIG for mechanical reasons, I want to derive the secret
> From the TLS.
> 
> I need to authorize the following:
>  1) DNS update of some data (NS, DS,  that NS points to) by
> Distribution Master (cloud/public system)
>  2) SOA query by Distribution Master by HNA.
>  3) AXFR by Distribution Master by HNA.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
>> Can we use TLS for authorization, assuming that we have trusted
>> certificates
>> at both ends?  Perhaps this is more of a: did anyone implement this?

> How is trust established?   Sure, doing TSIG over TLS is no problem.

Certificates are exchanged/created at manufacturing time (IDevID), and then
optionally updated to LDevID.  The certificate contains the name of the zone
which the HNA is authoritative for (or a control record pins the
certificate).

TSIG requires a shared secret, thus a database of shared secrets available
online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
if I have to use TSIG for mechanical reasons, I want to derive the secret
From the TLS.

I need to authorize the following:
  1) DNS update of some data (NS, DS,  that NS points to) by
 Distribution Master (cloud/public system)
  2) SOA query by Distribution Master by HNA.
  3) AXFR by Distribution Master by HNA.

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

Ted Lemon wrote on 08/06/2019 05:50:
On Jun 7, 2019, at 11:36 PM, Michael Richardson > wrote:
Can we use TLS for authorization, assuming that we have trusted 
certificates

at both ends?  Perhaps this is more of a: did anyone implement this?


How is trust established?   Sure, doing TSIG over TLS is no problem.


Bootstrapping trust is always going to be an issue no matter what we do.

There can be multiple ways to bootstrap this, and multiple possible 
providers pre-configured in the GUI.


Possible alternatives for further investigation:

1) something burned in at manufacturing time + trust between the 
manufacturer and the DNS Outsourcing Infra provider.


An initial query from the HNA to the infra could include a proposed 
domain name e.g. an AXFR or SOA query for .example.com sent to 
the DM together with SIG(0) signing of this name.


The signing could be done by a private key held at the manufacturer.

SIG(0) doesn't protect the wrapper, only the query data, so the query 
can be signed in advance off-line before anything like the homenet IP 
address is known.


The DNS outsourcing infra can check this signature either using an 
associated public key that is hosted on the manufacturer's DNS in a 
pre-agreed location. e.g. homenet-keys.manufacturer.com. Or the 
manufacturer could pre-share this public key with the DNS outsourcing 
provider out of band.


2) Out of band sign up using a public/private key held at the DNS 
outsourcing service provider at service sign up time (https + credit 
card + CGI script on the service provider's web site -> delegated domain 
name + SIG(0) signed delegated domain name query on the HNA for the 
initial query to the DM). The DM only needs to know the current valid 
public keys used for the SIG(0), and the private key and credit card 
details can be held elsewhere and regularly rotated.


3) Trust based on the TLS + certificate chain, rather than anything at 
the DNS application level. Currently very much hand waving on my part up 
until now. I've seen DANE being able to validate TLS connections based 
on a certificate chain (e.g. RFC 6698 DANE-TA(2) Trust anchor assertion, 
with a common trust anchor like let's encrypt X3 root) and was thinking 
we could leverage that somehow for mutual authentication, along with 
perhaps DNS over HTTPS (RFC8484). On the DM end that could use standard 
TLSA records published in the parent zone to validate the DM to the HNA. 
In the other direction we'd have to somehow to process a certificate 
from the HNA to identify the manufacturer or end user to the DM. But 
that's a well-known problem in web server land.


Thoughts?

--
regards,
RayH

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

Re: [homenet] securing zone transfer

[Ted Lemon]

On Jun 7, 2019, at 11:36 PM, Michael Richardson  wrote:
> Can we use TLS for authorization, assuming that we have trusted certificates
> at both ends?  Perhaps this is more of a: did anyone implement this?

How is trust established?   Sure, doing TSIG over TLS is no problem.

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Ray Bellis  wrote:
>> 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 ?

> Please don't invent something new.  DNS over TLS should be fine for
> channel security, with TSIG embedded inside that if additional
> authorisation is required.

Can we get away without TSIG?

Can we use TLS for authorization, assuming that we have trusted certificates
at both ends?  Perhaps this is more of a: did anyone implement this?

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

On 07/06/2019 21:03, Daniel Migault wrote:

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 ?


Please don't invent something new.  DNS over TLS should be fine for 
channel security, with TSIG embedded inside that if additional 
authorisation is required.


Ray

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Daniel Migault  wrote:
> 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 ?

And TSIG requires the Distribution Master to have a database of private
(symmetric) keys, which if disclosed causes havok.  (yes, DNSSEC can
partially save your bacon as we propose signatures be done on the homenet 
routers)

Can we use RFC7858 to authorize and provide privacy for AXFR?   We don't know
yet!  I believe that SIG(0) can be used for authorization, but I've never
configured that myself, or seen it in production.

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