Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-20: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

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 <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson