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

[Daniel Migault <[e-mail]>]

Hi Paul,

Thanks for the feedback. This is interesting. Please see my responses. I do
not see any need to add some text, but I am happy to do so if you think
that is needed.

Yours,
Daniel

On Sun, Oct 23, 2022 at 8:57 PM Paul Wouters <[e-mail]> wrote:

>
> On Thu, Oct 20, 2022 at 4:04 PM Daniel Migault <[e-mail]>
> wrote:
>
>> Hi Paul,
>>
>> Some brief element of response to your questions. While you are raising
>> comments within a DISCUSS see your comment as a very high level question on
>> what is the content of the draft with many questions related not to that
>> draft. I am happy to respond, but there is nothing actionable that can be
>> done, so please be more specific.
>> ----------------------------------------------------------------------
>>
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> This might be my misunderstanding
>>
>> of homenet, so hopefully easy to resolve.
>>>
>>> The HNA (hidden primary?) to DM (primary) DNS communication using DNS
>>> Update
>>> needs some kind of authentication, TSIG or SIG0 ?
>>
>> no
>>
>>> 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.
>>
>>> I
>>> don't see any DHCP options to relay authentication information for
>>> automatic
>>> deployment?
>>
>>
>> The FQDN "Distribution Manager FQDN" and "Reverse Distribution Manager FQDN"
>> are sufficent to set a TLS session.
>>
>> So I don't understand how this would startup and be able to setup a
>>> secure DNS update channel ?
>>>
>>
>> TLS needs only names. The certificates binds the names to a key used for
>> the authentication.
>>
>
> So you are using transport security as a means for data authentication.
>
>
> https://datatracker.ietf.org/doc/html/rfc5936#section-5  states:
>
>    Ensuring that an AXFR client does not accept a forged copy of a zone
>    is important to the security of a zone.  If a zone operator has the
>    opportunity, protection can be afforded via dedicated links, physical
>    or virtual via a VPN among the authoritative servers.  But there are
>    instances in which zone operators have no choice but to run AXFR
>    sessions over the global public Internet.
>
>    Besides best attempts at securing TCP connections, DNS
>    implementations SHOULD provide means to make use of "Secret Key
>    Transaction Authentication for DNS (TSIG)" [RFC2845 <https://datatracker.ietf.org/doc/html/rfc2845>] and/or "DNS
>    Request and Transaction Signatures ( SIG(0)s )" [RFC2931 <https://datatracker.ietf.org/doc/html/rfc2931>] to allow
>    AXFR clients to verify the contents.  These techniques MAY also be
>    used for authorization.
>
> 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).


> Unauthenticated AXFR is meant for zones that are open to the public and
> dns clients that want
> to grab a copy. It's not really meant for the actual primary <-> secondary
> channel. You might
> find that some DNS software insists on authentication if configured as
> secondary, as ACLs to
> just limit on IP address is really considered too weak.
>


> While using mutually authenticated TLS
> might be an option these days, most DoH/DoT/DoQ I believe only consider
> their use for privacy
> of unauthenticated connections. I'm not sure there are implementations and
> configurations out
>
there that deploy DoH/DoT/DoQ with mutually authenticated TLS.,
>
> so we only considered DoT in the document. Other protocols are left for
future work and only mentioned as potential examples. OARC35 [1] announced
ongoing support for XoT by NSD, Unbound, BIND, PowerDNS and [2] is the
commit "New configuration variables for client-side certificate".  I
believe we can reasonably say mutual authentication is on its way to become
widely available.

[1]
https://indico.dns-oarc.net/event/38/contributions/857/attachments/802/1470/oarc35-xot-slides.pdf
[2]
https://github.com/NLnetLabs/nsd/commit/044c4b5d267dba69996267164395c6ed799e389b



> Paul
>


-- 
Daniel Migault
Ericsson