Re: [homenet] [EXT] securing zone transfer

["Ray Hunter (v6ops)" <[e-mail]>]

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 AAAA 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 
CERTIFICATE-----\nMIIDSzCCAjMCFGy+Htuv9ErWhDkwvFU8mzocStmTMA0GCSqGSIb3DQEBCwUAMIGm\nMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQgQnJhYmFudDESMBAGA1UEBxMJ\nRWluZGhvdmVuMRMwEQYDVQQKEwpIb21lbmV0IFdHMRkwFwYDVQQLExBIb21lbmV0\nIEhOQSBEZW1vMRowGAYDVQQDExFkbS5ob21lbmV0ZG5zLmNvbTEfMB0GCSqGSIb3\nDQEJARYQdHJhc2hAZ2xvYmlzLm5ldDAeFw0xOTA2MjYwNzMyNTVaFw0yNDA2MjQw\nNzMyNTVaMB0xGzAZBgNVBAMTEnN1Yi5ob21lbmV0ZG5zLmNvbTCCASIwDQYJKoZI\nhvcNAQEBBQADggEPADCCAQoCggEBAMRQaLn7+WLhm80//Wl3gKqcDwEJrJfNM+gm\n+fpHdR2Ec15DxPoaL2wBP2bnvVu5mJGO8EC03fD9ZvFAJ46kD+K79JBMdpV4r+fO\ny/PeajXIV3pwW7mPxNyfI2N2xCwtBIps9neTZhQVTivpgvLeCyhiyoMeELca6BVg\nTB6B7R/IDlAbwEPuVesw5xzErulrbzvl/K2diTJyAega+c8uSQMLDWN72u4F98s+\nfePINqnkKJ3a9FNPVA7QBUmLBWIEVdnKuat7oAR5iveOqj9KIjBzMOsw4jCmt25F\nXRHtO0LSUE0SVtg49nuCClyBxAgdbcpuDnJXieC46jXy7OS0v6UCAwEAATANBgkq\nhkiG9w0BAQsFAAOCAQEAGm7WhvgN5QEwL5+nqx/hV05yNPAGS8be9ZHQwv+33fIU\n4BdBrQatFdV+IIUByOYpkJ1j9oxzXxm2f8QpZhZyJCPvVeJCmH3wOn2RVwFQHxix\n0VfQWVWSkW5N+o5itue3e6Toc0TPkHCEq0VfLJCbfJpZJ6wkwc/PYA/SK1ThAJY0\nlkFN9xtPwOm6Jm8L8jFe3FQMDT0oDsJOmWkud4ziRx3g10P5JZ0toShK6EdCSU1W\nCGiYCI9eaRzXJfVOH/jnjDJneAfp3ad0MKTcTFMplpjibkahmCnW9XcIentRP7mu\n0zC9KEHHRDJM8HiivyB0RaI9vmKc08MBThU0OBvJgQ==\n-----END 
CERTIFICATE-----\n"}

Thoughts?

Daniel Migault wrote on 12/06/2019 04:20:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> *On Behalf Of *Daniel Migault
>     *Sent:* June 7, 2019 4:03 PM
>     *To:* homenet <[e-mail] <mailto:[e-mail]>>
>     *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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>