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 <jacques.lat...@cira.ca
<mailto:jacques.lat...@cira.ca>> 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 <homenet-boun...@ietf.org
<mailto:homenet-boun...@ietf.org>> *On Behalf Of *Daniel Migault
*Sent:* June 7, 2019 4:03 PM
*To:* homenet <homenet@ietf.org <mailto:homenet@ietf.org>>
*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 <mailto:homenet@ietf.org>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
