Thanks Daniel. We've been waiting for your updated draft. tim
On Tue, Jan 24, 2023 at 10:14 AM Daniel Migault <mglt.i...@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.i...@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.i...@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+i...@narrans.de> >>> wrote: >>> >>>> On 2022-11-25 12:26 -05, Daniel Migault <mglt.i...@gmail.com> wrote: >>>> > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát < >>>> vladimir.cunat+i...@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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
