Tim Wicinski <tjw.i...@gmail.com> 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. 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. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
