I am happy to close this issue with DNS over mTLS. Yours, Daniel On Fri, Oct 28, 2022 at 7:19 PM Paul Wouters <paul.wout...@aiven.io> 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 <mglt.i...@gmail.com> 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 <paul.wout...@aiven.io> > 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 <mglt.i...@gmail.com> 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 <mglt.i...@gmail.com> >> 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 <paul.wout...@aiven.io> >>> wrote: >>> >>>> >>>> >>>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault <mglt.i...@gmail.com> >>>> 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
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
