Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
Tim Wicinski <tjw.ietf@gmail.com> Wed, 25 January 2023 02:55 UTC
Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA10EC169505 for <dnsop@ietfa.amsl.com>; Tue, 24 Jan 2023 18:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8wiit4r6lEUO for <dnsop@ietfa.amsl.com>; Tue, 24 Jan 2023 18:55:24 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 210DEC169501 for <dnsop@ietf.org>; Tue, 24 Jan 2023 18:55:24 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id mp20so44029071ejc.7 for <dnsop@ietf.org>; Tue, 24 Jan 2023 18:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=W+tgvxldVYwcmnO2DpiN8ePJwpY0SuvXhYz4YHq+NFg=; b=BKOT7RacMEkhgAkpvHvi446rJNVjxATD8ItSi0eMDoLF0Gynf3CkMQUnED4kYk1Mkk nTESN2Is8iXBcmH4OSAdNm9GJCR+yL9pefYeffyI4btbJASrlUwpg+s4XO2V+Sl4uqXg p4RMdqow9H/o/oPBLajpcG39SN0AdXOqRCpglfOeMkMX8ruOv27ZbLGybIy7h4wQ+0Sw Egsm7Kv/HaUO5/mEgJe3rsIMKo/ULZrAkz0vEnASNQ+zaxq8DyrTEHWIPDYx5PYe17hO +JpEcsAnRNrXrD705GCBelp5VlM/uGUuAz6g+rhf9OQuT2GWeskPqOj850rBGpitUG9N aMcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W+tgvxldVYwcmnO2DpiN8ePJwpY0SuvXhYz4YHq+NFg=; b=ITO4ygUClbNuy4CK0msEs5ewO7vIFB3mdpJjh7iig7JeZwZ7R4LrbFNGiKLLm1qzQP AxCebEHrXcW+B+xp/FAUhObhszi/Z1/Q1TO6ivgET9GNwzUmQKj7SuphnDxa9ckKEXbD VT/hbEk410AsfOsyHQtMjZEanxuwkbSkZ5PfzS1TganeBzXLVDbk7LrN/djhb1hVQX3r HLG6mOxELVbmA/p8dFtnsi+hxL3M4zSBZr3RwNYwo8BVyKTCEYdLswe/4zJeW3sK/qGu U6FC8KBkkAtao6Gw3ribvf5PTvBzNCWWL4LxjG1BW83zoyLAKfbz/ZduimRmUa9H5okG 82+A==
X-Gm-Message-State: AFqh2kokSMoRVcvkqcJr0Xk07tHaAdT364KMUbzktiI+nfakHuPYanao qMYZm6nuDdcfM/gfVn0jQKz4R27PSCupIu8XNoU=
X-Google-Smtp-Source: AMrXdXvPHgdJytBFnZkjzmSk3TP1BNoY56pcpeNtosT4kDGoUxY1W2gbNZhwE1Bswf+F/uuTBKLnj1bAYUBfrEZxfqQ=
X-Received: by 2002:a17:906:d28b:b0:7c0:e306:8930 with SMTP id ay11-20020a170906d28b00b007c0e3068930mr3946228ejb.386.1674615322631; Tue, 24 Jan 2023 18:55:22 -0800 (PST)
MIME-Version: 1.0
References: <CADyWQ+FwRaSdpSWXBDqCG9ZPNPiG4pGUx37PVtExbqVPr5ZfmA@mail.gmail.com> <65d26b98-e0d6-e69b-10d4-17632451cab6@nic.cz> <CADZyTk=wUydEv4X8KgHe3Mj0cZTmiaR3mjn_Z2n73U-eST-HPA@mail.gmail.com> <f397b7d4-fe4f-6000-5ce5-f2faa7b27b3e@nic.cz> <CADZyTkkdn__VhRRqwKDbNx3ymTR0KJmxoTN9aKMcox-JS=pW_A@mail.gmail.com> <m1wn7gd1ms.fsf@narrans.de> <CADZyTkkGfE2+SOwO-U40-iN3PnH2Cm7aoodDVxyp_rA-_iO8uw@mail.gmail.com> <CADZyTkmNYX4uzhYVChE8f7zQGdUPR2oD6qP7nLuVoeoStEnjJA@mail.gmail.com> <CADZyTk=sSTSB3Gio4AWvAsySnYARh_=LWb_3z2MTmYLv_hVcTw@mail.gmail.com> <CADyWQ+E3aJ67rJVAk=c_Ziv5WWTQDuq3rf7TEcMXYfqzC8mTSQ@mail.gmail.com>
In-Reply-To: <CADyWQ+E3aJ67rJVAk=c_Ziv5WWTQDuq3rf7TEcMXYfqzC8mTSQ@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Tue, 24 Jan 2023 21:55:11 -0500
Message-ID: <CADyWQ+EG0o3Dryocz3_DhhHANTa5gjhb7s4QdtEDm3SQHJU0eQ@mail.gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: Florian Obser <florian+ietf@narrans.de>, dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000070e31305f30dc38e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PE-m3oRilA11nqo5dRuVoxEQSeg>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2023 02:55:28 -0000
All Daniel and I noticed some weird formatting issues with his -02 draft, so he's pushed out -03 which is just fixing some broken formatting. Tim On Tue, Jan 24, 2023 at 2:28 PM Tim Wicinski <tjw.ietf@gmail.com> wrote: > Thanks Daniel. We've been waiting for your updated draft. > > tim > > > On Tue, Jan 24, 2023 at 10:14 AM Daniel Migault <mglt.ietf@gmail.com> > wrote: > >> Hi, >> >> If you think I have addressed all comments I received, if you believe >> that is not the case or if there are other comments, please let me know. >> Otherwise I expect to publish a new version by the end of the week. >> >> Yours, >> Daniel >> >> On Fri, Jan 13, 2023 at 5:21 PM Daniel Migault <mglt.ietf@gmail.com> >> wrote: >> >>> Hi, >>> >>> I am just wondering if you have any further comments or thoughts or we >>> declare your concerns being addressed. If you think we are fine, just let >>> me know. >>> >>> Yours, >>> Daniel >>> >>> On Tue, Jan 3, 2023 at 7:14 PM Daniel Migault <mglt.ietf@gmail.com> >>> wrote: >>> >>>> Hi Vladimir and Florian, >>>> >>>> Thanks for the comment regarding the use of 5011, to update the >>>> trust anchors. There are two situations where TAs need to be updated: >>>> * 1) configuration so the server instances are started with >>>> the up-to-date TA. >>>> * 2) a running resolver instance that has been started with the old TA >>>> and that needs a new TA to be considered. >>>> >>>> 1) configuration: >>>> >>>> TA trust store is an essential element of the configuration, and the >>>> document recommends having a special process to ensure every new resolver >>>> instance starts with the up-to-date TAs. TAs are so essential in the >>>> elaboration of trust that special care must be considered. This means that >>>> you need a robust mechanism to update the TAs trust store. >>>> Many DRO will not implement that process and instead rely on software >>>> updates to delegate the TA trust store update to the software vendor. >>>> If the DRO is willing to have a *special/specific* additional TA that >>>> is not updated delegated to the software vendor, the DRO will have to put >>>> in place such a mechanism. This is a critical operation and the DRO must >>>> have strong reasons to do so and must balance the additional operational >>>> risks versus the additional benefits. >>>> Given the essential aspect of the TA trust store, we recommend updates >>>> to be handled by an automated process (as opposed to manually being >>>> performed) BUT we also recommend the process to be manually supervised, >>>> that is with a manual confirmation. >>>> This mechanism is likely to require a specific relation between the DRO >>>> and the TA issuer with potentially the mechanism, being out-of band. To >>>> that point 5011 is probably not the best choice as mentioned by 5011 itself >>>> in section 8.3. >>>> >>>> 2) running servers >>>> >>>> For running resolvers, there is a need to ensure that the resolver is >>>> using the up-to-date TA. For this we recommend to follow 5011 that >>>> indicates how to automatically put significant trust into the newly >>>> published DNSKEY. On the other hand, if resolvers are retarted every days >>>> we may not need to have 5011 and monitor the roll over. I think that is the >>>> purpose of your comment. >>>> >>>> My impression is that there were some confusions in the text where 5011 >>>> was used. When it is limited to the running resolver, I would >>>> recommend enabling 5011 when the TA signer implements 5011 in case the >>>> software is not updated in a timely manner - or at least let the DRO decide >>>> whether it is willing to enable this option as a sort of insurance - even >>>> if it is relying on the software update as a general mechanism. I think it >>>> might be a bit different from what you proposed initially, which is to >>>> leave that to DRO with DNSSEC strong expertise and recommend to >>>> only stay with software updates. If there are any strong feelings on just >>>> relying on software updates and leaving 5011 to DNSSEC experts, I am also >>>> fine to push toward such a direction. >>>> >>>> I updated the text as follows: >>>> * clarifying TA updates for configuration versus running instances >>>> * clarifying 5011 dot not apply for updating configuration - at least >>>> as a primary mechanism >>>> * emphasize that the non default model is only recommended for DRO with >>>> DNSSEC expertise >>>> * adding that TA update for running resolver may be performed also by >>>> software update under the condition the DRO is likely to ensure a very >>>> recent release is run. >>>> * add a recommendation that when 5011 is used, the signer needs to >>>> implement 5011 timings. >>>> >>>> The changes can be seen there: >>>> >>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/dbb75b72a1806520ac77cf04424b0f6de0df29b5 >>>> >>>> Yours, >>>> Daniel >>>> >>>> On Sun, Nov 27, 2022 at 7:26 AM Florian Obser <florian+ietf@narrans.de> >>>> wrote: >>>> >>>>> On 2022-11-25 12:26 -05, Daniel Migault <mglt.ietf@gmail.com> wrote: >>>>> > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát < >>>>> vladimir.cunat+ietf@nic.cz> >>>>> > wrote: >>>>> >> I am surprised you would not recommend RFC 5011 >>>>> >> >>>>> >> 5011 needs persistent state, a thing that resolvers/validators >>>>> often don't >>>>> >> need at all otherwise (cache is safe to delete). 5011 doesn't >>>>> always work, >>>>> >> so you need to combine with some fallback mechanism(s) anyway - for >>>>> new >>>>> >> installations and for stale ones (missed rotation). Root rollover >>>>> has >>>>> >> happened only once in history, non-root TAs aren't that common, and >>>>> 5011 >>>>> >> algorithm isn't very simple, so the code can easily get some bugs >>>>> without >>>>> >> anyone noticing until it's too late. >>>>> >> >>>>> >> Lots of down-sides, so I rather put the TAs into SW updates, for >>>>> the root >>>>> >> TA case at least. I'd recommend trying to avoid non-root TAs, but >>>>> if I had >>>>> >> to choose, I'd put them into configuration. Again a thing that I >>>>> have to >>>>> >> provision *anyway*, so I get the occasional TA updates basically >>>>> for free, >>>>> >> without needing to worry about those 5011 disadvantages. >>>>> (occasional = >>>>> >> 5011 defaults to requiring 30 days of overlap) >>>>> >> >>>>> >> >>>>> > Oh! sure for the TA. My understanding of the text is that it >>>>> recommends >>>>> > 5011 for running instances, but that new instances are configured >>>>> with >>>>> > up-to-date TA that in most cases are updated by software update. So >>>>> yes I >>>>> > agree and will check this appears clearly. >>>>> >>>>> Another issue with 5011 is that it needs cooperation from the entity >>>>> signing the zone during a KSK rollover. 7583 spells this out in section >>>>> 2.2. I think Vladimír is hinting at this already, I'd say it should be >>>>> spelled out. Especially since this is aimed at non-DNSSEC-Experts as >>>>> you >>>>> were saying earlier in the thread. >>>>> >>>>> If a DRO unilaterally decides to put in a TA for example.com as >>>>> suggested in section 7.1.1 and using 5011 this will not end well if >>>>> they >>>>> don't tell the people operating the signer. They will probably not >>>>> follow the correct timing during a KSK roll. >>>>> >>>> >>>> >>>> -- >>>> Daniel Migault >>>> Ericsson >>>> >>> >>> >>> -- >>> Daniel Migault >>> Ericsson >>> >> >> >> -- >> Daniel Migault >> Ericsson >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Brian Dickson
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Brian Dickson
- Re: [DNSOP] Working Group Last Call for draft-iet… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Florian Obser
- Re: [DNSOP] Working Group Last Call for draft-iet… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter Thomassen
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter Thomassen
- Re: [DNSOP] Working Group Last Call for draft-iet… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Livingood, Jason
- Re: [DNSOP] Working Group Last Call for draft-iet… Viktor Dukhovni
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter Thomassen
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter Thomassen
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault
- Re: [DNSOP] Working Group Last Call for draft-iet… Peter Thomassen
- Re: [DNSOP] Working Group Last Call for draft-iet… Daniel Migault