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

Paul Wouters <paul.wouters@aiven.io> Fri, 28 October 2022 20:17 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAA4C14CF19 for <homenet@ietfa.amsl.com>; Fri, 28 Oct 2022 13:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkPVzm_MZXcP for <homenet@ietfa.amsl.com>; Fri, 28 Oct 2022 13:17:52 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D52C14CE20 for <homenet@ietf.org>; Fri, 28 Oct 2022 13:17:52 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id i21so9436646edj.10 for <homenet@ietf.org>; Fri, 28 Oct 2022 13:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=C+NqnOUHaDWfq/HfkpkaOatMBqQ4XwAX0NUGpd8+AnM=; b=TC/cETBuVkixae9jJ0L+Y8mRRAbASG8he6iAKz6Bh0XlhcMkbY4KGnFLPfb/9Do1Tj wIk2bwFA0IvXfeW4/L6pkXm6iDK30aC6FpKOoqW2fUJoHU8Unk2uuCx5CHYvWe3tiqSD aJz1SIZXE+GDk5RXeJzMt+Ortaxwzyj08/uTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C+NqnOUHaDWfq/HfkpkaOatMBqQ4XwAX0NUGpd8+AnM=; b=peaIzvfegIt7yXWQLHdopktzOmyPzhRLGCxRFKlIqzON2z2kplFSD3ZMXNIeK6MN4n XtnIprhPFzci4+h1q+SvyYKUIJC9lOQL4Agbfij4BRvESchigwzHQ/cGOpkJZdtyudYf i19DdjE4KI2Xcr1fc9j37biLQ9lZ50Wd+yAyj99bLmk+m/swEIoaXTlmslyiV9XOTNrp JTOhFLiuR2yUl3lJZFH09YRMsUow4qiPuncppG0Hg1YlF80iSofvUgi1qzzJjt5K0+2P NQV8f9qsUs5Vhqm5/iBFyZTGUrE+G8S+VLK/e50+ue7QCJMgPx0bihTsnjAO+eyLR2kF pE/g==
X-Gm-Message-State: ACrzQf2wb5CduEcjQ3wz9QeweaMcWNyJDG5yFbQX6wa5qbHriMAG0EUr uajoAU3WfliItlmXUYMzTw79qw==
X-Google-Smtp-Source: AMsMyM4nvFK6tu1GfJ9Da4nJ1fHUwQ6r2YP9RVTiZWwIht7EWbuZr06Ct99TjnN1ytPc1QiSLL3Q6g==
X-Received: by 2002:a05:6402:51c9:b0:45d:5efe:d1a3 with SMTP id r9-20020a05640251c900b0045d5efed1a3mr1177389edd.58.1666988270557; Fri, 28 Oct 2022 13:17:50 -0700 (PDT)
Received: from smtpclient.apple ([74.122.52.94]) by smtp.gmail.com with ESMTPSA id t20-20020a170906179400b0078df3b4464fsm1093050eje.19.2022.10.28.13.17.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 13:17:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-5F1E7B06-0524-4642-B729-FE8DBC9E476A"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul.wouters@aiven.io>
Mime-Version: 1.0 (1.0)
Date: Fri, 28 Oct 2022 16:17:47 -0400
Message-Id: <84758384-9B65-4EB6-BFA2-D0D6722C2D79@aiven.io>
References: <CADZyTkm05tQSxh7BNbVgy7LK8RCF=6N4fWF3pMdA0pdtGVH3cw@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-homenet-naming-architecture-dhc-options@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
In-Reply-To: <CADZyTkm05tQSxh7BNbVgy7LK8RCF=6N4fWF3pMdA0pdtGVH3cw@mail.gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
X-Mailer: iPhone Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/6LzzLP5MF051D8TOgVraiqhjJWs>
Subject: Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2022 20:17:56 -0000

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.ietf@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.ietf@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.wouters@aiven.io> wrote:
>>>> 
>>>> 
>>>>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault <mglt.ietf@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] and [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] and [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