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

[Matt Brown <[e-mail]>]

On Sat, Oct 22, 2022 at 4:11 AM Daniel Migault <[e-mail]> wrote:
>
> 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.

I agree with this in principle.

> 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.

But I think here is where we're reading RFC7858 differently - I do
read it as restricting how TLS is used in DoT, because it is an RFC
that is scoped only to a privacy purpose and for that reason has only
considered how to use TLS to provide privacy and server
authentication, not client authentication.

If RFC7858 didn't contain those restrictions on its scope, then I
think we'd be in agreement than any use of TLS is in scope, but that's
not what I see.

> 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.

The way I read 9103 (per the wording I quoted in the previous mail) is
that it builds a separate protocol (XoT) that inherits from DoT in
that it also uses TLS, but it is not DoT, hence it does not update the
DoT RFC.

> 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.

I guess at this point, I'd like to hear some other opinions to either
agree/disagree with the interpretation I've made of the situation - if
you follow my reasoning, it's more than just wording that is required
- either RFC7858 does need to be updated by this RFC, and/or you would
need to more fully specify the new protocol and security/privacy
considerations as 9103 did for XoT.

I understand that's a lot to be asking and I'm conscious that this is
only my first formal review and it's possible I'm taking an overly
strict interpretation of the existing standards... I don't think I am
FWIW, but I think it might be reasonable to solicit some more opinions
on whether this type of re-use of DoT is as straightforward/intended
as you read it, or brings up the challenges that I see.

Cheers

-- 
Matt Brown
DNS Directorate Member