Re: [Last-Call] [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

[Daniel Migault <[e-mail]>]

Thanks for the feed back. Please see my response inline. Note that we are
clarifying the use of transport protocols in the current document. For the
synchronization channel we mandate XoT, for the control channel we mandate
DoT - still with mutual authentication. I hope the line below adresse you
concern regarding mutual authentication.
Yours,
Daniel

On Wed, Oct 19, 2022 at 8:29 PM Matt Brown <[e-mail]> wrote:

> On Wed, Oct 19, 2022 at 3:25 PM Daniel Migault <[e-mail]>
> wrote:
> >
> > Hi Matt,
> >
> > Thanks for the review. I am only responding to the major comments - for
> now. I apologize for the partial response but I promise I will go through
> all other comments tomorrow (my) morning and hope you will still have this
> partial response (your) morning.
>
> No problem, likewise responding just to this first message now, and
> hopefully to your subsequent message later today!
>
> >> Major Issues (aka Not Ready):
> >>
> >> Mutual TLS and DoT - 3.2 and 4.6 recommend that the HNA and DM secure
> their
> >> control channel communications using mutual TLS and DoT - but DoT is not
> >> specified to support mutual authentication. While mutual TLS auth at the
> >> underlying TLS layer is clearly viable - how to integrate that at the
> DNS
> >> layer, and whether that is compatible with DoT on the existing port, or
> would
> >> need a further port allocation (and subsequent IANA consideration in
> 13) would
> >> need to be addressed. None of the alternative future protocols listed
> in 3.2
> >> support mTLS either as far as I am aware.
> >>
> >> Given the recommendation to use XoT (RFC9103) (which does specify mTLS
> >> capability) for the Synchronization channel in 5.1 - I wonder why this
> protocol
> >> has not also been considered for the control channel instead of DoT?
> >>
> > The section securing the Synchronization channel  mentions:
> >
> > The AXFR request from the DM to the HNA SHOULD be secured and the use of
> TLS is RECOMMENDED {{!RFC9103}}.
> >
> > So this is effectively what we rely on, mostly for the following
> reasons: 1) most of our exchanges are IXFR/AXFR and these are the one with
> the main concern, and 2) we wanted to reuse what is implemented in major
> distributions.
> > To put it in another way, we wanted the transaction between the HNA and
> the DM to be protected by TLS, and probably split from DNS over TLS to DoT.
> Would replacing DoT by XoT address your concern ?
>
> I'll confess my first encounter with XoT was in reading this draft, so
> I don't have a lot of context on its suitability for this use-case
> yet, but in as much as it looks at a glance to be a protocol that is
> intended to support mTLS (where DoT is not) in a context where
> authentication is expected, then I think it would address my
> concern... more below.
>
> > I would be happy to understand though why DoT would be an issue. The
> only point I can see is that 7858 specifies that it limits its scope to
> client -to resolver communications while admitting such restriction is due
> to a charter limitation. Since XoT mentions it is heavily relying on DoT,
> and resolvers and authoritative servers both handle DNS packets, I tend to
> assume that we may consider DoT can be used for any DNS communications, but
> I might be missing something.
>
> What I understand when I read this draft is a proposal is to take a
> protocol (DoT, RFC7858) with a primary purpose of providing *privacy*
> and which states in its design that authentication of clients is not
> in scope and use it in a context where *authentication of clients* is
> the primary requirement (e.g. the DM needs to know that it's receiving
> a connection from a client authorized to control the domain in the
> messages). That type of usage outside of the scope envisaged by
> RFC7858 brings two concerns to my mind:
> 1) *How* will clients/servers choose to implement the client
> authentication and will they be compatible with each other without
> further guidance/constraint being provided on how client
> authentication in DoT should be performed?
>

This is correct that if client authentication is disable it will not
happen. That said, we can believe that if that is what we are looking at
the TLS library will be configured appropriately. IN this case
the clients and the server are specific entities.

Regarding 7858, it does not say the client is not authenticated, it says
that the client authenticates the server and after the negotiation
completes the connection is encrypted. Client authentication is part of the
TLS negotiation.

Another example is also that when session resumption occurs, it becomes
hard to claim the client is not authenticated as TLS uses tha PSK-ECDHE
scheme.

To keep things simple, I would say if DoT were not defined we would have
said the traffic is secured by TLS. If we cannot use DoT we are happy to do
so, but I do not think using Dot is a concern there. That said, I am happy
to learn more if I am missing anything.

2) What are the security implications of authenticating clients in
> DoT? No doubt there are ways to do it that are not secure and should
> be avoided, but neither DoT or this now proposed draft examine this in
> any way.
>

XoT did that and optimized AXFR over TLS.

>
> Generally any time I see a security protocol/mechanism designed for
> one purpose (e.g. privacy) re-used in another context (e.g. client
> authentication) without significant examination of the implications
> and safety of that, I hear warning bells.



>
>
> Another point I would like to clarify is why another port would be needed
> for mTLS as this is a capacity announced by the TLS server. The support of
> mTLS is simply announced by the server by sending a CertificateRequest. The
> TLS client may only accept such communications. I do not necessarily see
> this as an issue, but again maybe I am missing something.
>
> Sorry for the confusion here, the point I was trying to make was
> simply whether DoT on the existing port could be used, or whether to
> get the authentication properties you need from the connection you
> actually need a new protocol (not DoT) that is designed fro
> authentication, not privacy to achieve that, and if that were the
> case, then such a hypothetical new protocol would presumably require
> its own port.
>
> Hope that clarifies.
>
> yes it does. I do not think we need a new port.


> --
> Matt Brown
> DNS Directorate Member
>


-- 
Daniel Migault
Ericsson