Hi Roman, Thanks for the follow-up. We were planning to catch some of th comments you raised to ensure the coherence of the document, so we are both thankful you pointed them to us and ashamed we did not clean this before you. So thank you very much for pointing this, this is very helpful.
Please see the link below and my response inline to your concerns.I believe the changes are addressing them. https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/10135f9e7edcb09aceaaf811d296fa723959e111 Yours, Daniel On Thu, Oct 20, 2022 at 9:53 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-20: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (updated ballot for the -20 text) > > (1) (per -18 and -20) The security properties of the communication channels > would benefit from refinement. > > Thanks for the effort to harmonize the text around TLS usage noted in my > ballot > on -18 per > https://mailarchive.ietf.org/arch/msg/homenet/Qc2sOcBD4P7j3LXYKP61pra7w_E/ > . > > The much clear text in Section 5.2: > > The entity within the > DOI responsible to handle these communications is the DM and > communications between the HNA and the DM MUST be protected and > mutually authenticated. > ... > The information exchanged between the HNA and the DM uses DNS > messages protected by DNS over TLS (DoT) [RFC7858]. > > Still appears to conflict with the text: > > -- Section 5.2 > While Section 6.6 discusses in more depth > the different security protocols that could be used to secure, it is > RECOMMENDED to use TLS with mutual authentication based on > certificates to secure the channel between the HNA and the DM. > > I propose to remove the sentence: OLD: The entity within the DOI responsible to handle these communications is the DM and communications between the HNA and the DM MUST be protected and mutually authenticated. While {{sec-ctrl-security}} discusses in more depth the different security protocols that could be used to secure, it is RECOMMENDED to use TLS with mutual authentication based on certificates to secure the channel between the HNA and the DM. NEW: The entity within the DOI responsible to handle these communications is the DM and communications between the HNA and the DM MUST be protected and mutually authenticated (see {{sec-ctrl-security}}). -- Section 14.1 > At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or > newer) SHOULD be supported. It is RECOMMENDED that all DNS exchanges > between the HNA and the DM be protected by TLS to provide integrity > protection as well as confidentiality. > > Per the TLS guidance in Section 14.1, should this document define it’s own > guidance, follow what comes with DoT/RFC7858 (which points to RFC7525), or > point to draft-ietf-uta-rfc7525bis? What is written here is slightly > different > than RFC7858 so I recommend draft-ietf-uta-rfc7525bis or something > stronger. > > I do not see the specific guidance we provide unless the recommendation of the TLS version. As far as I can tell we only follow RFC7858 and RFC9103 guidelines. If the recommendation of the TLS version is the problem I would recommend removing the sentence. The RECOMMENDED applied to RFC9103 that may protect or not NOTIFY and SOA. The reason we would prefer to stick DoT / XoT is to prevent too many variants of implementations - as much as possible and encourage the re-use of largely deployed and maintained systems/implementations. Typically someone simply sets its own TLS channel - which could work. Now I agree that DoT XoT are more focused on the DNS part than aon the TLS and that recommendations specific to TLS should be included in the text. Unless I completely missed the comment, I propose the following text which I think addresses your concern. OLD: At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or newer) SHOULD be supported. It is RECOMMENDED that all DNS exchanges between the HNA and the DM be protected by TLS to provide integrity protection as well as confidentiality. As noted in {{!RFC9103}}, some level of privacy may be relaxed, by not protecting the existence of the zone. This MAY involved a mix of exchanges protected by TLS and exchanges not protected by TLS. This MAY be handled by a off-line agreement between the DM and HNA as well as with the use of RCODES defined in Section 7.8 of {{!RFC9103}}. NEW: The TLS communication between the HNA and the DM MUST comply with {{!I-D.ietf-uta-rfc7525bis}}. The Control Channel and the Synchronization Channel respectively follow {{!RFC7858}} and {{!RFC9103}} guidelines. The highest level of privacy provided by {{!RFC9103}} SHOULD be enforced. As noted in {{!RFC9103}}, some level of privacy may be relaxed, by not protecting the existence of the zone. This MAY involve a mix of exchanges protected by TLS and exchanges not protected by TLS. This MAY be handled by a off-line agreement between the DM and HNA as well as with the use of RCODES defined in Section 7.8 of {{!RFC9103}}. (2) Section 6.5 > > The provisioning process SHOULD provide a method of securing the > Control Channel, so that the content of messages can be > authenticated. > > Per the changes made in (1), and the strict requirement to mutually > authenticate with TLS, why isn’t this a MUST? > removed. Note that this is typically some of the sentences we planned to clean up due to the clarification of the transport channels. We are planning to review fully the paper to remove all the remaining ones - if some remains and ensure some coherence with the changes recently provided. I feel ashamed you did it before us... but that is greatly appreciated. Thank you for taking that time. > > ** Section 1.3 > > [per -18] > When the resolution is performed from within the home network, the > Homenet DNSSEC Resolver MAY proceed similarly. > > [per -18] I’m not sure if this my misreading of the behavior of internal > clients. To clarify, the (internal) Homenet DNSSEC Resolver will “... > resolves > the DS record on the Global DNS and the name associated to the Public > Homenet > Zone (myhome.example) on the Public Authoritative Servers.”? Why would the > internal resolver serving a request for an internal client for an internal > service go to the Global DNS if the information if it could come from the > internal Homenet Zone it is already configured with? As an operational > consideration, why go outside of the network if you don’t need to? As a > privacy consideration, why leak the request to an outside entity if the > network > already has the information. > > [per -20] Thanks for the revised text: > On the other hand, to provide resilience to the Public Homenet Zone > in case of WAN connectivity disruption, the Homenet DNSSEC Resolver > SHOULD be able to perform the resolution on the Homenet Authoritative > Servers. > > -- Please also point out that the use of the Homenet resolver would enhance > privacy since the user on the home network would no longer be leaking > interactions with internal services to an external DNS provider and to an > on-path observer. > > added > -- Is there a reason this can’t be a MUST? > > yes. The first one is that such an authoritative server may not exist or the HNA may play both roles. The second one is that recommendations apply to resolvers (or authoritative servers) that could be a bit of a border line to the scope of the current document. The homenet WG planned to publish a naming document for homenet where this would be detailed but that document never got finalized - this is actually why the publication of this document took so much time. As a result, the SHOULD seems sufficiently broad to put the focus on it, while not providing a detail that derails the discussion. > -- Editorial (comment level, but adding here for convenience) Consider if > you > want to use the “DNSSEC Resolver” or “DNS(SEC) Resolver” (as was introduced > later) since DNSSEC is not mandatory. > > > I changed it in 8 places > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Warren, John and Paul’s DISCUSS positions. > > Thank you for addressing my COMMENTs. > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
