Retransmitting the points I made at the microphone at the IETF. 1) We don't have a quantum safe signature algorithm that we've selected for DNSSEC and AFAICT, while there are a lot of candidates, even the crypto folks aren't to the point of saying "use this" for any of the candidate algorithms. 2) Once (1) is done, there's at least a few years to agree and produce an RFC. 3) Once (2) is done, there's at least a 5 year uptake period to get the new algorithm support into the resolvers. (And there's the self-same problem that it's impossible for the root publisher to know whether or not a resolver actually supports the new algorithm. It may make sense to actually do a PERT style "what has to happen when and before what" diagram to document the moving pieces and to help figure out if there are any tasks we can complete early (e.g. figuring out how to serve *really big signatures* even if we don't know what the signature mechanism might be). Mike
Michael StJohns <msj@nthpermutation.com> wrote: > It may make sense to actually do a PERT style "what has to happen when > and before what" diagram to document the moving pieces and to help > figure out if there are any tasks we can complete early (e.g. figuring > out how to serve *really big signatures* even if we don't know what the > signature mechanism might be). PERT charts have been under appreciated in software planning this century. I don't quite know why. Maybe it reveals too much about poor planners. ** This is exactly what I'd like to see ** I'd like to see the really-big-signature problem worked on. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
participants (2)
-
Michael Richardson -
Michael StJohns