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
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
