On Dec 31, 2020, at 2:09 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > > On 31/12/2020 21:48, Eric Rescorla wrote: >> 1. Don't allocate a code point at all >> 2. Allocate the code point but in some manner that makes clear >> we don't endorse it (effectively what TLS does for algorithms >> like this) >> 3. Allocate the code point without comment > > FWIW, I kind of agree with ekr, both as to the options > and on my current preference to not too easily loosen > up for DNSSEC.
To be clear, the loosening that is being discussed is from making it "standards required" to "RFC required". (We briefly discussed going to "specification required", but there was little appetite for that.) > That said, I wonder as to the actual deployment of algs > that we'd not recommend, especially given the relative > scarcity of DNSSEC signing. Well, exactly. This discussion arose because a few Russian folks want the revised GOST algorithms to have a code point allocated. Currently, for them to do that, the IETF would have to put the new GOST algorithms on standards track. We did that for the last algorithm, but it is not clear if we want to do that again. > Does anyone have a pointer to survey-like material that > has a focus on rarer algorithms in DNSSEC? One reason to > ask is that from a first glance it looks to me like .ru > isn't using gost, which would be telling, if correct. > > To be clear: I don't think spending much time debating > how to handle algs for an infinitesimal number of zones > is that worthwhile, so that'd be another reason to prefer > the status quo, if that is the case. The status quo (standard required) will likely absorb a lot of time for the IETF if the WG decides to move the revised GOST forward. It will also probably land in the CFRG. Reducing the requirement to RFC required allows their document to be informational. The WG already has RFC 8624 that talks about what implementers should do with various algorithms. Clearly, it will need to be updated for the revised GOST regardless of whether the WG changes the IANA considerations. Also, as a reminder, this isn't only about GOST. In the coming years, there will be a raft of post-quantum signing algorithms with different signature and key size ratios that people will want adopted. Putting every one of them on standards track seems onerous to some of us. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
