The net effect is the same in respect of new algorithms. I'm fine with checking conformance if the algorithm is known, it feels like a low bar.
Rejecting sigs because you don't know how to check feels like a huge impediment to technology: The use of the new algorithm is now gated by the ability of registrars to adopt it, rather than the rate of deployment by the actual zone holders. -G On Tue, Nov 1, 2016 at 10:15 AM, Geoff Huston <g...@apnic.net> wrote: > >> On 1 Nov. 2016, at 3:37 am, Matthew Pounsett <m...@conundrum.com> wrote: >> >> >> >> On 31 October 2016 at 00:22, George Michaelson <g...@algebras.org> wrote: >> It is only my personal opinion, but I believe registrars are incorrect >> in performing crypto alg checks on proffered DS, and this is an >> entirely unwarranted, and incorrect understanding of their role. It >> conflates one public good (checking) with another public good >> (registry of data into the DNS) and assumes one out-ranks the other: >> It doesn't, and the inability to track crypto alg change, makes the >> checking wrong. Its the lesser of two evils to stop checking, and >> permit unknown algorithms through. >> >> I think this needs to be flagged up. Either they should be told to >> stop, or the requirements for algorithm agility which their role >> places on them should be made explicit. >> >> I know of a couple of cases where registries perform similar checking. >> Depending on the implementation, the registrar may need to perform the >> checks themselves in order to prevent future upstream calls from generating >> errors. >> >> I think the way I'd implement this is to perform "best effort" checking. If >> I know the algorithm, then make sure that the DS/DNSKEY supplied is correct >> for that algorithm. If I don't know the algorithm, pass it through as-is >> (and log it so that I can have my developers investigate and add that algo >> to the check library). > > I pretty much agree with Matt here. I believe that this falls into a similar > area as checking the NS records, and the justification is approximately along > the lines of “if it lives in the zone file I should check that resolvers > won’t encounter errors - to the extent I can” > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
