Folks,
I am organizing a panel session within the DNSSEC Workshop during the upcoming ICANN meeting in Cancún in March on the subject of DNSSEC provisioning. There are two related but somewhat distinct topics. One is the update of the DS record when the DNS provider rolls the key. The other is how multiple DNS providers coordinate when each is signing the zone. Various proposals exist to solve each of these problems, but none has been fully accepted, and each suffers from a gap in the provisioning process.
Depending on who is on the panel and we can cover either both topics or just the first topic. I also intend to organize a session on these topics in Paris in May at the ICANN Global Domains Division Summitt and/or the DNS Symposium. Also, the dnssec-pr...@shinkuro.com mailing list is specific devoted to these two topics.
Please let me know if you're interested in participating and if you have a position on how to address these problems.
Details
What is the path forward for automating solutions to these two provisioning problems? Are new protocols needed? What changes are required of registrars, DNS providers and/or registries?
With respect to updating DS records, the solution space is basically a two by two matrix, with a subordinate third dimension:
The subordinate third dimension is whether the KSK, DS or both are communicated.
The solution in RFC 8078 is the pull/registry solution with support for both KSK and DS. It was developed by a couple of DNS providers and is on the IETF standards track, but, so far as I can tell, is being adopted by a relatively few ccTLDs and is not gaining any traction within the gTLD community. In contrast, GoDaddy has suggested its Domain Connect software could be extended to allow a push/registrar solution for DS updates.
With respect to coordination among multiple DNS providers, Shumon Huque, et al's Internet-Draft https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec-01 [tools.ietf.org] sets for a scheme for multiple DNS providers to coordinate cross-signing of the same zone when it's served from multiple providers.
I have both a general and a specific interest in this. The general interest is in seeing some sort of solution be adopted in order to facilitate smoother operation and greater adoption of DNSSEC. My specific interest is a guess that if the registrant could add the names of his DNS providers into the registration details, it would make both of these coordination processes much easier.
Thanks,
Steve Crocker
--
Thanks,
Steve Crocker
You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.
To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zvLpW6MYR-oeAEw9wjxg9AmUGh3hRN3%3D8NuCRezamGXCRg%40mail.gmail.com.
Steve Crocker <st...@shinkuro.com> wrote:
>
> Please let me know if you're interested in participating and if you have
> a position on how to address these problems.
I'm in the process of trying to persuade management to send me to Paris in
May, so this is somewhat provisional. But I have opinions :-)
Firstly, RFC 7344/8078 CDS/CDNSKEY should be seen as a protocol between a
zone's key management and signing system, and the zone's delegation
management system. Although it was designed to span the child/parent
boundary, it is also great within a child's systems for disentangling two
distinct parts by providing a standard interface between them. So the code
that a child uses to manage its secure delegation doesn't need to ask the
signer about any key timing metadata, it can just look at the zone apex.
The more tools we have that do useful things with CDS/CDNSKEY, the more
incentive there is to deploy them. WRT delegation management I think we
should aim for the least restrictive deployment model possible. That is,
registrars AND registries should be encouraged to act on CDS/CDNSKEY
records. I don't want the registr*s to be able to point fingers at each
other saying, well, we'd like to support it but the other kind of registr*
is holding us back.
WRT CDS vs CDNSKEY, there are enough registries that require DNSKEY that
signers must generate both, and client-side tools must be prepared to use
either CDS or CDNSKEY. Although I would prefer it if registries could all
agree on one way to do things, that seems too much of a hurdle :-)
There's a broader issue of the structure of the market: at the moment,
specialist hosting providers are in a difficult position because it's hard
for them to do interesting things with the DNS if they are not either the
domain's owner or its registrar. And being a registrar is fiendishly
difficult. Cloudflare is a good example of this: they originally
championed RFC 7344/8078 (as an independent hosting provider), but
eventually became big enough to justify becoming a registrar, since that
was a faster way to solve their problems.
A related awkwardness is that implementation of CSYNC and CDNSKEY would
help hosting providers, but I expect registrars don't particularly want
their hosting business to be eroded by a protocol that makes it easier for
their customers to move their web sites (etc.) elsewhere.
That's probably enough positioning for now...
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
partnership and community in all areas of life
A related awkwardness is that implementation of CSYNC and CDNSKEY would
help hosting providers, but I expect registrars don't particularly want
their hosting business to be eroded by a protocol that makes it easier for
their customers to move their web sites (etc.) elsewhere.Yes, I have heard the argument that registrars don't want this to happen because it reduces their ability to control the registrant's choice of service providers.
I'm not sure how much resistance there actually is as opposed to rumors of such resistance.
Steve Crocker <st...@shinkuro.com> wrote:
>
> Thanks! I have taken the liberty of copying the
> dnssec-pr...@shinkuro.com mailing list. If you would like to
> join the list, let me know.
I think I've already subscribed, but if I haven't, please add me!
> I don't understand the model and roles you have in mind when you refer
> to the zone's key management and signing system on the one hand and the
> zone's delegation management system on the other hand.
To be super concrete, I use BIND for key management and zone signing. BIND
doesn't come with any tools for talking to registr(ar|ie)s so I have my
own. My delegation scripts just look at zone files to find out what the
delegation should be - they don't need access to the key files, which for
BIND normally implies access to the secret keys (if, like me, you don't
have an HSM!). So my signer can run on an isolated system that can't talk
to the outside world, whereas my delegation scripts can run on a separate
system with a different security posture. And my delegation scripts don't
need to be changed if I switch signer to Knot DNS or whatever, because the
scripts get information about what the DS records should be using an open
standard, rather than signer-specific utilities.
> If I understand the point you're making, the DNS provider could generate
> the CDS and/or CDNSKEY records and then either the registrar or the
> registry could pull those records. The only coordination that would be
> needed is for the registry and registrar to agree on which one one will be
> polling. It seems logical to me that the registry is the one who decides.
Right, though my argument is that if the registry fails to act then that
should be taken as a de facto decision that registrars can/should do so.
> This seems to me to be feasible, although I believe some registrars
> prefer to have complete knowledge of the data passed to the registry.
Is there an EPP mechanism for registries to tell registrars about changes
like this?
> I can imagine a small but potentially annoying issue with respect to
> timing if both records are required by the client. What happens if one
> of these is put into the zone before the other and the client sees the
> first one but not the second when it polls?
I think there are a couple of more general questions underlying this:
RFCs 7344 and 8078 leave quite a lot of the business logic unspecified,
such as the polling interval, the hold-down time (if any), CDS vs CDNSKEY
vs both, how carefully to check all the nameservers, etc. Do we need one
blessed way?
To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/DM6PR02MB4108415D54766C17D97ED999DA0B0%40DM6PR02MB4108.namprd02.prod.outlook.com.
Not currently, Rich. Doing anything here would require additional specification/protocol work either in EPP or somewhere else.
Scott
Thanks, Scott; that’s what I thought but I wanted to ask the expert 😊
--
You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.
To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zvLWGv3VCtEsMw-A7YAh-wGk9%2BM9P947uzq4xsus8TWq6A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zv%2BYdjdiVq5zSe5%3DVgoPbU%3D14decieaPigPMGfzxM_w-pA%40mail.gmail.com.
Steve,
GoDaddy is still committed, but I have arranged for an internal DNS expert to participate. He is extremely familiar with the subject matter and will be much more able to engage in the multi-signor problem. His name is Brian Dickson, and he is cc’d here.
--Rich
From: Steve Crocker <st...@shinkuro.com>
Sent: Friday, February 28, 2020 9:22 AM
To: DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Cc: Stephen D. Crocker <st...@shinkuro.com>
Subject: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting
Notice: This email is from an external sender.
Folks,
--
Confirmed, I’m the new rep for GoDaddy on this panel.
So, a small clarification on the Domain Connect proposal:
I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.
Push/Pull DS:
The DS maintenance push/pull issue:
I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.
E.g.
Cross-Signing:
We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.
One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.
I look forward to the panel, and if possible feedback by registry operators between now and then.
Brian
Confirmed, I’m the new rep for GoDaddy on this panel.
So, a small clarification on the Domain Connect proposal:
- The Domain Connect (extension) would be for the initial DS Record needed to transition a zone from insecure to secure.
- It is not being proposed for maintaining DS records when the key rolls.
I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.
Push/Pull DS:
The DS maintenance push/pull issue:
- This should be exclusively focused on mechanisms for signaling and/or conveying updated records.
- We see no reason to deviate from the use of the CDS and/or CDNSKEY records and signatures, for the content used by the registries for processing the updates.
- The security properties of CDS and CDNSKEY are essential to the security of updating the records at the TLD.
- CDS is preferred (to avoid pre-publishing DNSKEY data itself), but some registries currently require DNSKEYs be supplied.
- It should not be mandated that both always be supplied
- The only interoperability required is Zone to Registry, so each implementer/operator should be free to choose (publish both, or only one, or always CDS and sometimes CDNSKEY where required by the registry)
- I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.
E.g.
- Is the registry concerned about polling load requirements only?
- Would registries be okay with pulling the updated records if they get signaled that a given zone has a new CDS or CDNSKEY?
- Perhaps signal with a new OPTYPE specific to this mechanism?
- Similar to NOTIFY but limited to only this purpose?
- Would it be desirable by some registries for the “push” party to supply the updated records as DNS data sent directly?
- I.e. similar to UPDATE, but specific to this use case? Answer section containing the CDS/CDNSKEY and RRSIG records?
- How would registries want to protect their notification channel against abuse or DOS attacks? Suggested methods:
- DNS Cookies
- IP ACLs derived from zone apex information
- SOA record field (e.g. MNAME)
- New RRTYPE(S) at the apex
- New underscore name holding ACL-specific A/AAAA records
- Queried dynamically, or polled periodically, or pushed similar to the DS/DNSKEY mechanism?
- Would need to be signed
- Which of the above would be mandatory vs optional (e.g. DNS Cookies)?
- We think standardizing on ALWAYS publishing CDS (and optionally CDNSKEY, possibly dependent on parent domain) would be wise, and simplify the implementers’ choices
- This ensures that registries can migrate between push/pull models without adversely affecting zone publishing mechanisms
- This reduces the architecture discussions to a much simpler, “How to signal a pull by the registry, and/or how to push records to the registry”
Cross-Signing:
We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.
One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.
I look forward to the panel, and if possible feedback by registry operators between now and then.
From: Steve Crocker <st...@shinkuro.com>
Date: Friday, February 28, 2020 at 5:16 PM
To: "Brian P. Dickson" <bdic...@godaddy.com>
Cc: Richard Merdinger <rmerd...@godaddy.com>, DNSSEC Provisioning <dnssec-pr...@shinkuro.com>, "Stephen D. Crocker" <st...@shinkuro.com>
Subject: Re: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting
Notice: This email is from an external sender.
Brian,
Very glad to have you on board. I will put you on the panel instead of Rich.
Thanks for your very meaty message. My comments are embedded in line.
Steve
On Fri, Feb 28, 2020 at 2:53 PM Brian P. Dickson <bdic...@godaddy.com> wrote:
Confirmed, I’m the new rep for GoDaddy on this panel.
So, a small clarification on the Domain Connect proposal:
- The Domain Connect (extension) would be for the initial DS Record needed to transition a zone from insecure to secure.
- It is not being proposed for maintaining DS records when the key rolls.
Interesting. See comment/question below re using it just for the first time.
I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.
Good.
Push/Pull DS:
The DS maintenance push/pull issue:
- This should be exclusively focused on mechanisms for signaling and/or conveying updated records.
I sense there is an implied or understood alternative that some people may want. From past discussions with Rich, I think I heard some 3rd party DNS providers wanted to update NS records or perhaps other records, not just DS records. Is this what you're alluding to?
[bpd] Actually, no, I meant only that either a push occurs, or a “signal” is sent that triggers a pull (which is a different model than “poll”). Adding other records to the set of things to get updated (DNS operator -> Registry) is certainly open for discussion. I think there would need to be some investigation by participants to the impact of individual record types, and whether those align with their process flows.
But if there’s consensus, I think updating NS is also a possible thing. (IMHO, it would need to be a new record type, call it “CNS”, to avoid causing further NS issues over and above the parent/child zone cut overloading and non-authoritative-vs-authoritative thing.)
The important thing would be that everyone would need to accept the registry as being the “source of truth” at all times, for records that propagate this way. That might require changes to how some registrars handle NS updates, for example, where the registrar might currently consider itself the source of truth.
- We see no reason to deviate from the use of the CDS and/or CDNSKEY records and signatures, for the content used by the registries for processing the updates.
I thought it was the position of registrars such as GoDaddy that they needed to be in the loop -- at least informed after the fact -- whenever the DS record changed in order to have an accurate copy of the data in the registry. It seems you are not requiring this. Do I understand correctly?
[bpd] Yes, you understand this correctly. The DS record copy in the registrar really only is required at the time it is being sent to the registry, either at set-up time or if the registrant is manually updating it. Once the DS in the registry has been updated or set, the registrar copy is redundant. It is likely an issue for updating how DS (and possibly DNSKEY) values are treated, which might in some cases require registrars to update some of their code. However, if/when the DNS operator to registry path is used, any discrepancy between the registrar and registry is technically moot (as the registrar value is no longer being used).
- The security properties of CDS and CDNSKEY are essential to the security of updating the records at the TLD.
- CDS is preferred (to avoid pre-publishing DNSKEY data itself), but some registries currently require DNSKEYs be supplied.
- It should not be mandated that both always be supplied
- The only interoperability required is Zone to Registry, so each implementer/operator should be free to choose (publish both, or only one, or always CDS and sometimes CDNSKEY where required by the registry)
Yes, it seems to me it would be ok for each registry to specify whether it wants CDS, DNSKEY or both. Of course, there would have to be some way for the 3rd party DNS provider to find out which of these is required for the registry.
[bpd] I concur. Hopefully a standard can be established that would allow for discovery of registry DNSSEC requirements and parameters. E.g. what algorithms are supported, what key sizes, is the registry using NSEC or NSEC3 or something else, maybe information about whether the authority servers for the registry do minimal responses, maybe information about NSID structure/scope, anything else that might be helpful for either automation purposes or human diagnostic purposes. When there were 7 TLDs, it wasn’t a big deal, but today…
As I said above, I thought there was substantial resistance within the gTLD registrar community to the idea they would not be in the loop. You're obviously in a much better position to speak to this than I am. Moreover, I don't have any reason to take a side on this. I'm just trying to keep track of the various competing ideas.
[bpd] I’d be interested in hearing the positions of other registrars, and rationale(s). I think the restriction to these changes is that it is only applicable if DNSSEC is being used, and the updates involve signed data from the apex of the zone. Any changes to non-DNSSEC zones would be excluded from these methods of updating the registry, for obvious reasons (security).
- I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.
E.g.
- Is the registry concerned about polling load requirements only?
- Would registries be okay with pulling the updated records if they get signaled that a given zone has a new CDS or CDNSKEY?
- Perhaps signal with a new OPTYPE specific to this mechanism?
- Similar to NOTIFY but limited to only this purpose?
- Would it be desirable by some registries for the “push” party to supply the updated records as DNS data sent directly?
- I.e. similar to UPDATE, but specific to this use case? Answer section containing the CDS/CDNSKEY and RRSIG records?
- How would registries want to protect their notification channel against abuse or DOS attacks? Suggested methods:
- DNS Cookies
- IP ACLs derived from zone apex information
- SOA record field (e.g. MNAME)
- New RRTYPE(S) at the apex
- New underscore name holding ACL-specific A/AAAA records
- Queried dynamically, or polled periodically, or pushed similar to the DS/DNSKEY mechanism?
- Would need to be signed
- Which of the above would be mandatory vs optional (e.g. DNS Cookies)?
- We think standardizing on ALWAYS publishing CDS (and optionally CDNSKEY, possibly dependent on parent domain) would be wise, and simplify the implementers’ choices
- This ensures that registries can migrate between push/pull models without adversely affecting zone publishing mechanisms
- This reduces the architecture discussions to a much simpler, “How to signal a pull by the registry, and/or how to push records to the registry”
These are all excellent questions.
I'll offer one thought that reflects my technical bias, but let me quickly add that I don't have a reason to push in either direction. I tend to prefer "push" solutions because it feels to me the control is more certain, and it's also likely to be quicker. A polling solution seems to me to require longer periods to allow time for the polling cycle to take place, and it also seems to me that if polling doesn't take place, it won't be obvious until it's too late.
[bpd] I think it’s six of one, half-a-dozen of the other. Even if updates to the registry happen very quickly and propagate to all the TLD’s servers, there is still the latency for updates caused by resolver caches. Absent a “big red button”, that’s always a problem, especially for the TTL of TLD records. (I think that is a problem that could stand some work, but there’s no obvious solution just yet.) Affirmative state change is good, however, so I think either a true “push”, or a similar “notify” type mechanism (which would include an acknowledgement response) is potentially beneficial. A lot of uncertainty is how receptive TLD operators are to this kind of mechanism, so it’s probably a bit early to go too far down this road just yet.
Cross-Signing:
We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.
One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.
Model 1 is essentially a single authoritative 3rd party provider, with others acting as secondaries to the first. That's the less interesting and less general case. The real challenge is how to deal with multiple 3rd party providers, each of which generates and uses its own keys. One important advantage of having co-equal operation is it makes it easy to transition from one provider to another. If there is a single master, the problem of transitioning from one provider to another remains unsolved.
[bpd] I need to think about this a bit more, but one method might be a transition like this: model 1 (old primary) -> model 2 (co-primary) -> model 1 (new primary). Model 2 is more complex to operate/maintain, I think? So as long as the transition mechanism is well-defined (with a small number of api calls), there’s possibly value in having a slight preference for one of the providers to be the primary, as it simplifies some aspects of the cross-signing.
Cross-signing requires both the exchange of keys in order to inlcude them in Keyset, the full set of DS records has to exist in all of the copies of the zone, right?
[bpd] Cross-signing requires the KSK private key, plus all of the public keys for the ZSKs and the KSK (repeated for all the algorithms and key roll additions etc).
If only one KSK is used, that KSK signs the keysets, and each provider’s zone contains the same keyset and RRSIG(dnskey set).
If multiple KSKs are used (one per provider), the keyset in each operator’s zone will be that operator’s KSK, plus all of the ZSKs, and that KSK signs that unique dnskey set.
(I think one variant could be that all the zones include all the KSKs, but only one KSK is used to sign the dnskey set (the KSK for that operator). Not sure if that is better in terms of consistency.)
The DS set only has to match the set of (active) KSKs, regardless of the quantity of ZSKs. The DS is only in the parent zone (the TLD).
The main thing is that a validator gets a set of DNSKEYs which includes all the ZSKs and an appropriate set of KSKs (one currently, possibly more than one). The signature is calculated using the KSK (or each KSK if more than one is present), and compared to the RRSIG received. Plus, the hash of the KSK(s) is compared to the set of DS records. There has to be one match for validation to succeed, on both the hash and on the RRSIG validation.
Basically, all that really matters is that each operator’s DNSKEY set is returned to a resolver, and that all of the records are present before doing the signature calculation/validation step. This prevents an attacker from doing a downgrade attack by filtering some of the DNSKEY records. All of the ZSKs are needed from all the operators, because of cached RRSIGs and the need to be able to validate them, regardless of which operator they were obtained from.
I look forward to the panel, and if possible feedback by registry operators between now and then.
For those who have read this far, let me add that this panel discussion is really part of an ongoing process. The discussion and ideas developing for this panel will be carried forward for further development on this mailing list and at meetings in the future.
Thanks,
Steve
[bpd] Yep, and looking forward to all of that.
Brian
On 29 Feb 2020, at 02.16, Steve Crocker <st...@shinkuro.com> wrote:As I said above, I thought there was substantial resistance within the gTLD registrar community to the idea they would not be in the loop. You're obviously in a much better position to speak to this than I am. Moreover, I don't have any reason to take a side on this. I'm just trying to keep track of the various competing ideas.
[bpd] Follow-up comment/question in-line below…
From: 'Erwin Lansing' via DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Reply-To: Erwin Lansing <er...@lansing.dk>
Date: Monday, March 2, 2020 at 1:11 AM
To: Steve Crocker <st...@shinkuro.com>
Cc: DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Subject: Re: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting
Notice: This email is from an external sender.
Catching up after some travel. If I do my timezone calculations right, I should still be able to participate, that said, even for a ccTLD registry, wrt DNSSEC we are probably even more quirky than most. More on that in a separate email.
[bpd] I think the nature of the specific data, i.e. DS (or DNSKEY), can be described as being not just redundant, but actually ephemeral. It is used exactly once, during the set-up, and never again. The only time a registrar would send DS or DNSKEY data to a registry after the initial set-up, would be if the data changed and a new DS or DNSKEY was being submitted. Thus, the actual DATA in the registrar is use-once-only. It is safe to discard once the transaction succeeds. Even if updates happen via another channel, those are one-way updates which are also ephemeral in nature. There is literally zero benefit for a registrar in tracking those, as those would never be re-used once the registry has applied them (which would need to be the case before the registry notified the registrar in that potential scenario/model.)
[bpd] Given the above, I think it would be helpful to have a session somewhere with registrars to communicate these kinds of details, listen to their concerns, and address those concerns. Is there a good place or event for those sorts of discussions?
Brian