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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
