Wes, Thanks for your comments and support. I'm in complete agreement. See inline for an additional comment.
Steve On Fri, Oct 11, 2024 at 6:16 PM Wes Hardaker <[email protected]> wrote: > Tim Wicinski <[email protected]> writes: > > > I do believe the 8624bis authors and the WG are open to updating > the values for the table > > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > > So, yes and no. > > Steve, Russ, Warren and I had a long conversation about this (actually > multiple: at least one in a verbal discussion and a bunch more over > email). > > My stance is that we are solving two different problems with the two > documents, and that they should not be combined. > > 1. Problem one: moving the existing registry components into the IANA > table, and this allows for the encoding of any set of values for > recommendations. This includes the possibility of encoding values sets > that are entirely different than what the phasing document prescribes. > In other words, I do not think that the phases MUST be the only way to > encode recommendations and that the 4 new recommendation columns in > RFC8624bis should be a super-set of the (currently) perceived best path > through a deployment life cycle. Furthermore, I think the IANA table > should be capable of storing multiple phasing life-cycles if someone > else comes up with an alternative set of values to stick into the > 8624bis defined columns. > > 2. draft-crocker-dnsop-dnssec-algorithm-lifecycle is proposing a > solution to a different, but related, problem: as an algorithm > progresses through a life-cycle what should the ideal values be for each > of the 4 columns in 8624bis for a given point in time? This seems > highly useful if we can come to agreement on that progression. > > I do think that weird corner cases may even suddenly require different > states to exist besides the ideal phasing considered in the > algorithm-lifecycle document. Consider the case when an algorithm is > fully deployed and actively in use for "phase 4" (MUST MUST MUST > RECOMMEND). What if that algorithm is (very) suddenly very > cryptographically weakened? I'd argue that jumping straight to phase 7 > would be problematic. Certainly the "Use" columns should immediately go > to MUST NOT, but I'm not so sure about the Implementation columns -- I > think there is a transition period where that algorithm must be still be > implemented because the world can't transition over night. > It will be interesting to see how many times, if ever, sudden transitions are required. I think a jump from 4-Mainstream to 6-Deprecated would probably be the right step. Moving immediately to 7-Obsolete causes the problem that triggered the creation of this lifecycle documentation. In prior discussions and presentations, I also suggested an algorithm might move from 3-Available to either 5-Phaseout or 6-Deprecated if it is determined that the algorithm is weaker or less suitable than had been expected. > > I also think that the 8624bis table should support cases where the > community has some other random exception for the current state of > affairs of something. Hopefully this is rare, or even "almost never". > But I note that we're already in that state: the values that are in > 8624bis are functionally taken from the past without modification (at > least until the gost/sha1 documents are also published to change the > values). Thus, the current RSASHA512 values that we have defined today > (NOT RECOMMENCED/MUST/NOT RECOMMENDED/MUST) do not even map to a phasing > value set in the algorithm-lifecycle document. I believe we must > allow for this possibility in the 4 columns even when we may wish it > won't be used. > > The downside of my thinking? You can absolutely come up with completely > useless combination sets (MUST NOT implement, and MUST use). But by > requiring a standards action to change the values, it's up to the IETF > consensus process to ensure we don't make such crazy decisions like that. > It will take several years -- or decades -- before there is enough experience to see whether there are useful combinations that are not consistent with the lifecycle model. Perhaps this will be both fun and useful for someone's master's thesis in 15 to 20 years. Steve sender
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
