On Wed, Oct 19, 2022 at 3:25 PM Daniel Migault <mglt.i...@gmail.com> 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?
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.
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.
--
Matt Brown
DNS Directorate Member
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
