Re: [homenet] securing zone transfer

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

Ted Lemon wrote on 08/06/2019 05:50:
> On Jun 7, 2019, at 11:36 PM, Michael Richardson <[e-mail] 
> <mailto:[e-mail]>> 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 <hn-ULA>.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
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>