Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)

[Daniel Migault <[e-mail]>]

Hi Paul,

We implemented the change and used DNS over mutually TLS (DomTLS) to
represent DoT and XoT. We do believe we have address all your concerns for
this draft and your DISCUSS can be lifted. The other document has its
own DISCUSS and I do not believe there is any need to hold a DISCUSS. Of
course, the DISCUSS being raised does not mean no changes can be made.

Yours,
Daniel

On Fri, Oct 28, 2022 at 7:32 PM Daniel Migault <[e-mail]> wrote:

> I am happy to close this issue with DNS over mTLS.
> Yours,
> Daniel
> On Fri, Oct 28, 2022 at 7:19 PM Paul Wouters <[e-mail]>
> wrote:
>
>> I did see the previous reply and it doesn’t make too much sense to me.
>>
>> You could say “mutually authenticated TLS” or something but I find it a
>> little odd that these two things which are separate are one option.
>>
>
> Perhaps it is better if we resolve the other document DISCUSS first and
>> then see if that helps resolve this DISCUSS.
>>
>> Sent using a virtual keyboard on a phone
>>
>> On Oct 28, 2022, at 17:06, Daniel Migault <[e-mail]> wrote:
>>
>> 
>> I thought I responded to it, but was not able to find the response...
>> until I realized the response is not inline... but in the main part of the
>> email. I am copying the response here - and take that inline text seems
>> much clearer.
>>
>> The reason we mentioned both RFC7858 and RFC9103 is that the
>> communication between the Homenet Naming Authority (HNA) and the
>> Distribution Manager (DM) involves two different channels. The Control
>> Channel that aims at configuring/managing the Synchronization Channel (i.e.
>> the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while
>> the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two
>> channels always go in pairs. As both are using DNS over TLS we use the
>> mnemonic 'DoT' for the Selected Transport. From what you are saying, it
>> might be clearer to just mention 'TLS' for the Selected Transport as DoT
>> might be really tightened to 7858. If you think this is clearer, I am happy
>> to do so as well as with any name that you think is clearer.
>>
>> Yours,
>> Daniel
>>
>> On Fri, Oct 28, 2022 at 4:17 PM Paul Wouters <[e-mail]>
>> wrote:
>>
>>> Was there a problem with my suggested CURRENT / NEW suggestion ?
>>>
>>> Sent using a virtual keyboard on a phone
>>>
>>> On Oct 28, 2022, at 15:14, Daniel Migault <[e-mail]> wrote:
>>>
>>> 
>>> Hi Paul,
>>>
>>> I am wondering if there are any remaining concerns left for
>>> the draft-ietf-homenet-naming-architecture-dhc-options document and
>>> anything you would like us to address to lift your discuss.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault <[e-mail]>
>>> wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Thanks for the follow-up. The reason we mentioned both RFC7858 and
>>>> RFC9103 is that the communication between the Homenet Naming Authority
>>>> (HNA) and the Distribution Manager (DM) involves two different channels.
>>>> The Control Channel that aims at configuring/managing the Synchronization
>>>> Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS
>>>> RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS
>>>> 9103. The two channels always go in pairs. As both are using DNS over TLS
>>>> we use the mnemonic 'DoT' for the Selected Transport. From what you are
>>>> saying, it might be clearer to just mention 'TLS' for the Selected
>>>> Transport as DoT might be really tightened to 7858. If you think this is
>>>> clearer, I am happy to do so as well as with any name that you think is
>>>> clearer.
>>>>
>>>> Yours,
>>>> Daniel
>>>>
>>>> On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> While TLS gives you privacy,
>>>>>>
>>>>>>> the DNS Update cannot be done with only TLS (as far as I understand
>>>>>>>>> it).
>>>>>>>>
>>>>>>>> please develop, but just in case, we do not use dns update to
>>>>>>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT.
>>>>>>>>
>>>>>>>
>>>>> This to me was not clear and a missed reference by me. While you name
>>>>> RFC9103, the text states:
>>>>>
>>>>> DNS over TLS: indicates the support of DNS over TLS as described in
>>>>>    [RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 <https://datatracker.ietf.org/doc/html/rfc9103>].
>>>>>
>>>>> I should have looked more closely at the references, and I would have
>>>>> realized 9103 is about DNS XFR over TLS. That document indeed explains
>>>>> that XoT uses mutually authenticated TLS which provides the
>>>>> authentication for the XFR streams.
>>>>>
>>>>> My suggestion:
>>>>>
>>>>> Current:
>>>>>
>>>>> DNS over TLS: indicates the support of DNS over TLS as described in
>>>>>    [RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 <https://datatracker.ietf.org/doc/html/rfc9103>].
>>>>>
>>>>> New:
>>>>>
>>>>> DNS Zone Transfer over TLS: indicates the support of DNS Zone Transfer
>>>>> over TLS as described in [RFC9103]
>>>>>
>>>>>
>>>>
>>>>> The reference to RFC7858 is misleading - it only deals with stub to
>>>>> recursive.
>>>>>
>>>>> If you think stub to recursive is in scope, it might be better to use
>>>>> two DHCP options as these two things
>>>>> seem to be very separate protocols (that just both happen to use DNS
>>>>> and TLS)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> So you are going against the RFC 5936 SHOULD.
>>>>>>>
>>>>>>> I even had to look this up because I didn't know you could do an
>>>>>>> AXFR as a secondary
>>>>>>> from a primary without DNS level authentication. Apparently you can,
>>>>>>> but you SHOULD not.
>>>>>>>
>>>>>>> That is what we do. TLS provides enough security to replace TSIG /
>>>>>> SIG(0).
>>>>>>
>>>>>
>>>>>
>>>>> Reading 9103 made that clear to me now, but the text in the document
>>>>> did not. Perhaps that can be stated more clearly ?
>>>>>
>>>>> Paul
>>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Migault
>>>> Ericsson
>>>>
>>>
>>>
>>> --
>>> Daniel Migault
>>> Ericsson
>>>
>>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson