Hi Michael.
Michael Richardson wrote on 02/12/2022 02:56:
In re-editing I found that the section 7.1 is a bit vague about where the
Notifies go. Ray Hunter please comment.
https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-22.html#name-securing-the-synchronizatio
Since the Synchronization Channel is from the DM->HNA, it can't be issued
there.
It must therefore be the case that the zone update Notifies go into
the Control Channel.
Not necessarily.
A Notify IMVHO is just an unsolicited signal from a (hidden) primary to
a secondary that they may want to check for updated content.
So any decent server should probably already
1) check that the notify arrives from somewhere where the server trusts
the source of the zone information
2) use the notify as an indication that the local refresh timer should
be expired e.g. set a flag for later action by a timed background task.
3) rate limit how often this happens
4) check for updates in zone content by the standard mechanism via the
Synchronization Channel of DM->HNA, .
My assumption therefore was that the Notify from HNA->DM COULD be
unprotected and transported as DNS over UDP as per RFC1996.
HNA could learn the correct source and destination IP address to use for
the Notify by reversing information learned from previous inbound
DM->HNA synchronization channel connections.
But the text below doesn't say this, and is pretty wishy-washy about about
whether TLS is used or not. It could very well be the case that Notifies are
*not* protected at all.
that was my assumption.
Since the Control Channel is not a regular DNS channel, and likely is port
853 DoT, it seems unlikely that a Notify to port 53 would go the right place.
OTH, bringing up DoT just to send the Notify might be considered by some to be
overkill. TLS resumption tickets to the rescue is my opinion.
I'm looking for objections to:
1) Notifies go across the Control Channel (DoT)
2) They are always sent in TLS.
This means that the text will get moved around a bunch.
My view is that TLS is overkill, although I have no objection to it. It
potentially adds some privacy.
The text as it appears now:
## Securing the Synchronization Channel {#sec-synch-security}
The Synchronization Channel uses standard DNS requests.
First the HNA (primary) notifies the DM (secondary) that the zone must be
updated and leaves the DM (secondary) to proceed with the update when
possible/convenient.
More specifically, the HNA sends a NOTIFY message, which is a small packet that
is less likely to load the secondary.
Then, the DM sends AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request.
This request consists in a small packet sent over TCP (Section 4.2
{{!RFC5936}}), which also mitigates reflection attacks using a forged NOTIFY.
The AXFR request from the DM to the HNA MUST be secured with TLS {{!RFC8446}})
following DNS Zone Transfer over TLS {{!RFC9103}}.
While {{!RFC9103}} MAY not consider the protection by TLS of NOTIFY and SOA
requests, these MAY still be protected by TLS to provide additional privacy.
When using TLS, the HNA MAY authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE {{?RFC6698}}.
In addition, to guarantee the DM remains the same across multiple TLS session,
the HNA and DM MAY implement {{?RFC8672}}.
The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they only arrive
from the DM Synchronization Channel.
In this case, the HNA SHOULD regularly check (via a DNS resolution) that the
address of the DM in the filter is still valid.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Kind regards / Met vriendelijke groet,
Ray Hunter
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
