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