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

[Daniel Migault <[e-mail]>]

Hi Matt,

Thanks for the follow-up, please see my response.

Yours,
Daniel

On Thu, Oct 20, 2022 at 4:37 PM Matt Brown <[e-mail]> wrote:

> On Thu, Oct 20, 2022 at 5:53 PM Daniel Migault <[e-mail]>
> wrote:
> >
> > 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:
> >> >
>
> <snip>
>
> >> > 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.
>
> If I'm understanding you correctly, the argument is that the
> underlying TLS libraries support mTLS, so can be used in the way
> proposed, even though it is outside the scope of what is standardised
> in RFC7858. This may very well be true, but in my understanding it's
> then incorrect to call this using DoT. To me, what is proposed is to
> build further protocol specifics (client authentication) on top of DoT
> - which may work, but if that is what is intended, then it needs to be
> done explicitly - e.g."this standard extends the DoT specification to
> support client authentication via mTLS" or similar.
>
> Are there existing DoT implementations using mTLS to authenticate
> clients to DoT servers that you are aware of? I could not find any in
> a quick search.
>
> As you noted previously the XoT spec provides a good example that
> building on top of DoT in this way is feasible and a reasonable thing
> to do - which is useful - but I think two things should be noted from
> that comparison (emphasis mine below):
> 1) XoT does not say it uses DoT, it says (end of Introduction):
> "encrypting zone transfers using TLS [RFC8499] -- **based closely on
> DoT [RFC7858]** -- seems like a simple step forward. This document
> specifies how to use TLS (1.3 or later) as a transport to prevent zone
> collection from zone transfers." - e.g. it is clear that what is being
> described is not DoT, but something close to it.
> 2) The level of detail in how to accomplish that extension is higher
> than I see present in this draft (e.g. RFC9103 7.1, 7.3 cover TLS
> establishment specifically, and 9.3.3 and 10.0 then cover the addition
> of authentication, etc).
>
I got your point, but I think there is a confusion between the subset of
functionalities being used versus those provided by the protocol. TLS
provides client authentication and its part of TLS, any use of TLS unless
explicitly specified provides this capacity. To my understanding this is
why architect solutions at the protocol level - that is to guarantee any
new scenario that maybe we did not think in the beginning can work.
DoT defines a way to carry DNS messages over TLS and does not restrict the
functionalities provided by TLS - at least at a high level. That some were
using a particular set of functions of TLS does not prevent others from
using others. None of the DoT implementations uses its own TLS
implementation that prevents client authentication - which would be a light
TLS but not TLS. Put in other words, client implementation is supported by
all DoT implementations. DoT clearly identifies session resumption which in
TLS 1.3 is very close to a client authentication. All of this just to
mention that TLS has multiple built-in functionalities.

If the TLS of 9103 were different it is likely that 9103 would update - at
least in some ways - 7858. This is not the case and section 9.3.3 and 10.0
do not mention any changes that apply to DoT and the TLS in XoT and DoT is
the same.

Now, if you believe that just saying DNS is encapsulated as in DoT with a
mutual authentication seems more appropriate, I am happy to consider the
wording that you think is more appropriate.




> Cheers
>
> --
> Matt Brown
> DNS Directorate Member
>
> On Thu, Oct 20, 2022 at 5:53 PM Daniel Migault <[e-mail]>
> wrote:
> >
> > 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
>
>
>
> --
> Matt Brown
> DNS Directorate Member
>


-- 
Daniel Migault
Ericsson