Re: [homenet] outsourcing architecture [meeting notes]

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

Hi Daniel,

Here's my input where there wasn't time to provide at the mic in the 
meeting.

Daniel Migault wrote on 19/11/2019 10:36:
> Hi,
>
> So my notes/comments regarding the feedbacks received are:
> * mentioning the work on axfr over tls
No problem with referencing this and it's helpful feedback.

I currently only protect the HNA based on a simple IP ACL in knot (allow 
DM for AXFR), which is effective, and doesn't eat resources on the HNA.

IMHO We almost certainly already have the required credentials in place 
for mutual authentication of the synchronisation channel (from the 
control channel) and I presume there's no issue with re-using these 
credentials in the reverse direction for the TLS session from DM -> HNA.

In my implementation, the HNA could authenticate itself to the DM by 
using the same certificate signing request signed by a private 
certificate from the DM that was already provided out of band, based on 
a trust anchor at the DM using it's own self-signed root certificate. 
There's no need for any additional public certificate.

The DM could authenticate itself to the HNA using a public Let's Encrypt 
certificate with subject common name matching the DM, with a trust 
anchor of the standard baked in root certs. The name of the DM is 
already provided out of band for initiating the control channel.

> * cds needs to be placed in the homenet zone by the HNA
We already foresaw using CDS for ongoing maintenance of the DS key 
[RFC7344 + RFC8078].

See Section 5.2 of our draft.

/Though the HNA may also later directly update the values of the DS via 
the Control Channel, it is RECOMMENDED to use other mechanisms such as 
CDS and CDNSKEY [RFC7344] are used for key roll overs./

So I have no problem with the DM updating the DS key based on CDS 
(Section 4) during normal operations.

However, this can't be the ONLY method of maintaining the DS (which I 
believe was the question asked at the mic).

Because we're bootstrapping the trust between the HNA and the DM, and 
there's little or no previous knowledge of the other party, we need 
additional checks and balances. The KSK may also be lost.

That's why in my implementation we can always create, update, and delete 
the DS directly via the control channel.

The TLS transport on the control channel provides the authenticated 
channel referred to in Section 3.1. of 8078.

The control channel includes mutual authentication using certificates in 
my implementation (we know who we're talking to = authenticated).

I also check if this particular HNA is authourised to update this 
particular DS RR.

/When an UPDATE is received by the DM on the control channel, the 
message SHOULD be checked for authenticity (e.g. the source zone in the 
update message corresponds to the common name of the certificate used by 
the HNA), and then the DM SHOULD use the received information to 
configure the synchronization channel./

That was covered in some text I submitted on the github, but it isn't 
included in the published version 9. I missed that. We should go through 
and make sure those additional checks on the control channel, and why 
they're needed, are correctly documented.

The other options suggested in RFC8078 are inadequate or technically 
difficult IMHO.

RFC8078 Section 3.2 Extra check is technically hard IMHO

What would we check?

RFC8078 Section 3.3. Accepting after delay is inadequate.

We're talking public internet here. Otherwise there could be a resource 
exhaustion attack on the DM by an attacker inserting random DS RR's, or 
denial of service attacks by timing updates on unsuspecting HNA's that 
haven't renewed their DS for a while, or cant defend it quickly enough 
if they're offline.

RFC8078 Section 3.4 Accepting with Challenge

Possible, but then we'd have to define a (new) challenge response protocol.

ACME only works once DNS delegation is established, so you have a 
chicken-egg problem.

RFC8078 Section 3.5 Accepting from Inception
See comments on RFC8078 Section 3.3

> * considering factory reset and removal of the provisioned keys ? - we 
> need to think of this scenario.
Already covered in my implementation.

The KSK keys for the zone are generated on the HNA itself, and are never 
ever transmitted or stored outside the HNA, so if they're lost (either 
by factory reset or hardware replacement) there needs to be a recovery 
mechanism that does not depend on any state stored on the DM or HNA.

As long as an HNA still has a copy of the certificate signed by the DM, 
or they can grab a new certificate from the DM supplier (out of band), 
they can either update, delete, or replace the existing DS RR without 
knowing the old/lost KSK.

That was one reason for using Section 3.1 of 8078 for authenticating the 
creation, update, and deletion of DS RR's via the control channel.

> * securing the synchronization between primary/secondary with TLS ? 
> Feed backs are still unclear to me whether 1) we need to secure this 
> channel. If we secure it, the document considers TLS - as for the 
> control channel.
I was initially reluctant to specify this, but the general desire and 
push for privacy of naming from the market is clear, and it wouldn't be 
that difficult to implement.

So I'd be OK to include "SHOULD use the same protection on the 
synchronisation channel as the control channel" in our draft if the WG 
agrees.

>
> Yours,
> Daniel
>
>
> _______________________________________________
> 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>