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