Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Hi,

Ted made a valid point about "running code" in this thread.

So I've been experimenting with various configurations.

My conclusions:

1) We definitely need to properly secure communication between the HNA 
and the DM for control traffic.


This needs to be an explicit part of the draft.

2) Authentication based on the physical connection, plus source IP 
address, plus correlation of the source address against the contents of 
the RR *might* be sufficient for transactions between the HNA and the DM 
for reverse zones - all communication is guaranteed to be contained 
within a single AS.


Current best practice of using IP ACL's + BCP 38 for filtering 
communication could work in this case. The DM would then check whether 
the contents of the PTR updates arrived from a source address associated 
with the HNA.


We'd need to add some text saying the HNA should select source addresses 
for reverse zone updates appropriately (to make sure the updates came 
from an address issued via IA-PD from this ISP).


3) for communication between the HNA and a DM for forward zones, we 
definitely need to specify something stronger, because the DM 
potentially has to serve HNA's scattered over the entire Internet.


4) TSIG isn't going to scale operationally IMHO.

Too many keys to manage. Keys have to be stored on line within the DM. 
Losing keys means compromising the whole service, and it is difficult to 
recover from.


5) SIG(0) has similar problems.

Bootstrapping the trust might mean the expiration time would have to be 
so large that replay attacks will come into play.

And recovery is difficult.

6) DNS over an existing standard FOO secure transport looks promising.

The amount of traffic arriving at a DM should not be so large or time 
critical as the traffic to the resolvers, and capacity can be scaled by 
increasing the numbers of DM's.


There is also existing front-end hardware acceleration available. So the 
secure transport could theoretically be terminated on an dedicated 
acceleration box, and the DM only then needs to speak native DNS.


7) DNS over TLS can almost certainly be made to work without any new 
standards, but it will require extensive coding as support seems pretty 
limited off the shelf.


It also has the added benefit that client authentication can be built 
into the transport.


So I've been playing around with the DM being authenticated by public 
certificates to the HNA (HNA would incorporate root certificates burned 
in at the factory), and the HNA being authenticated to the DM by a 
client-specific certificate that is signed using a self-signed 
intermediate CA certificate from the DM. The DM then trusts the 
certificates it has issued to the client HNA's simply by installing the 
root CA cert on the DM: there's no client specific configuration required.


Since the HNA anyway has to be configured to use the DM, and some trust 
has to be  established, I don't see this as an onerous burden in the 
sign up process.


8) DNS over HTTPS doesn't bring us anything extra in this case IMHO.

It actually presents additional challenges with coding alternate 
transports and parsing (POST or GET HTTP1.1 HTTP2) etc.

Others may disagree, so the draft could use a "recommend DNS over TLS"

9) IMHO we should also standardize the trust-booting process into a JSON 
file, that can either be fetched via HTTPS or pasted into the HNA.


This for the same reasoning for inter-operability that DNS standardized 
the file representation of the zone file in RFC1035 Section 5.


For a start, I came up with the following, although I'm sure we can 
improve as we get more experience in what parameters are needed for each 
implementation.


I came up with 4 parameters:

dm_axfr    fqdn of the DM for axfr (so the HNA can apply IP filters on 
inbound requests)


dm_ctrl    fqdn of the DM for ctrl (so the HNA can send updates to the 
DM control channel e.g. if the HNA renumbers it would send an NS record 
and  record update)


zone    the zone that is being delegated

hna_certificate    client certificate encoded as a single line with 
literal '\n' replacing cr and lf characters (common practice in existing 
equipment when pasting certificates)


This would also work for a reverse zone, although obviously it's a 
different DM etc.


Sample:

{"dm_axfr":"dm.homenetdns.com","dm_ctrl":"dm.homenetdns.com","zone":"sub.homenetdns.com","hna_certificate":"-BEGIN 

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

Re: [homenet] [EXT] securing zone transfer

[Daniel Migault]

Hi Jacques,

I agree the HNA cannot generate the full zone out of the box and needs some
information such as the NS. It also needs some information to configure the
primary / secondary relation such as the the IP of what we now call the
Distribution Master. DNS update on a specific zone seems tempting
especially as it is available code for it. Though I might be biased, but i
am not sure we need TSIG. I need more thoughts.

Yours,
Daniel

On Tue, Jun 11, 2019 at 3:00 PM Jacques Latour 
wrote:

> 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
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [EXT] securing zone transfer

[Ted Lemon]

I agree. That’s not my point. I actually put some ideas for how to something 
similar with that piece of the puzzle in one version of the homenet naming 
architecture. I’ll see if I can find it. 

Sent from my iPhone

> On Jun 11, 2019, at 8:48 PM, Michael Richardson  wrote:
> 
> I don't think it will work as the protocol for a homenet to publish a public
> zone to the Internet without some additional security and setup. At least,
> that's my feeling at this point.

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

Re: [homenet] [EXT] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
>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.

> Have you looked at draft-ietf-dnssd-srp
> (https://tools.ietf.org/html/draft-ietf-dnssd-srp-01
> )?

Ted, I didn't think it was relevant, but I read it anyway.

It has been sometime since I tried to grok the SRP stuff, and last time it
was mostly to understand the more homenet related things.

  dnssd-srp> In other network environments, updates for names ending in
  dnssd-srp> "default.services.arpa" may be rewritten internally to  names with
  dnssd-srp> broader visibility.

Our goal with front-end-naming is to provide the "rewritten internally 
function".

I found section 2.3.2.  Testing using standard RFC2136-compliant servers out
of place. I think it belongs in an appendix?

This dnssd-srp protocol seems like it will work wonderfully within a homenet
(or small to medium sized campus). I think that is the goal.

I don't think it will work as the protocol for a homenet to publish a public
zone to the Internet without some additional security and setup. At least,
that's my feeling at this point.

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

[Ted Lemon]

On Jun 11, 2019, at 2:59 PM, Jacques Latour  wrote:
> 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.

Have you looked at draft-ietf-dnssd-srp 
(https://tools.ietf.org/html/draft-ietf-dnssd-srp-01 
)?

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

Re: [homenet] [EXT] securing zone transfer

[Jacques Latour]

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