In article <2bcc20b2-9de0-a808-4e2c-054ff48f3...@icann.org> you write: >On 10/15/19 12:11 PM, John R Levine wrote: >> I just heard a most interesting talk at M3AAWG about postquantum crypto and >> particularly about the NIST candidate >algorithms. Many of them have much larger key or signature sizes than any >current algorithm, like 10,000 bits or >more. Some are a lot slower than others. Has anyone been looking at how >these algorithms would or would not work >with DNSSEC? > >Yes. (More specifically: https://datatracker.ietf.org/doc/draft-hoffman-c2pq/, >which is very casually being worked >on in the CFRG.) > >Or, define "work with". Falling back to TCP for getting DNSKEY records might >not be a big deal.
Depends. A 1K key is one thing, a 50K key is another. If you are rotating keys so you have multiple key records, and the keys are large enough, what happens when the result packet is bigger than 64K? >Or, maybe wait until NIST has gotten more through the process, given that key >size and signature size are among the >many factors they are considering. > >> NIST is accepting comments and the talk said they particularly want comments >> from industry on how this would >affect existing applications. The talk was by Brian LaMacchia, who opined it would e useful to send in some comments about how various increases in key size, signature size, and signing or verification speed would be likely to work with DNSSEC. It sounds like they're paying a lot of attention to TLS in their algo evaluations, a lot less to DNSSEC or DKIM or other protocols. I'll see if I can get his slide on the key and signature sizes for the candidate algorithms to be roughly as strong as a 3K RSA key. One of them would need a 500,000 bit key which makes me wonder what they were thinking. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
