Re: [regext] CDS/CDNSKEY vs. EPP update prohibited
> On Dec 2, 2022, at 1:49 PM, Hollenbeck, Scott > wrote: > I lean towards "prohibited means prohibited". DNS service providers can be > compromised, too, and I'd prefer to see steps taken to explicitly remove the > state prior to a DNS update vs. allowing some actors to bypass the state. Exactly. I agree wholeheartedly. The point of belt-and-suspenders is to have a safety mechanism in case _either_ part fails. There’s no reason to go to the work for only half the value. -Bill signature.asc Description: Message signed with OpenPGP ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP Transport Service Discovery
Yes, because the registry can improve over time, and the registrars can update their software over time. If we don’t give updated client-side software a mechanism to discover that the server now supports improved transport, we get gridlock. -Bill > On Mar 20, 2024, at 3:40 AM, Jim Reid wrote: > > > >> On 20 Mar 2024, at 02:11, Hollenbeck, Scott >> wrote: >> >> we need to consider how a client can discover the transport services >> provided by an EPP server. > > I’m sceptical about that. Though I don’t object to the idea. > > Surely clients get told about the EPP server’s supported transports as a > result of signing the registry’s contract? If so, do we *really* need > something else? > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP Transport Service Discovery
The. Certificate problem can be dealt with as elsewhere: switch to DANE and stop accepting CA certs. -Bill > On Mar 20, 2024, at 5:33 AM, Francisco Obispo wrote: > > This is a neat idea, > > Is there a reasoning or use case for such need? > > One of the challenges that I see, is that knowing the server address is one > thing, but generally clients (registrars) keep the connections open for a > long period of time, so the need to reduce the connection speed may not be a > big advantage in practice. (if this is the argument) > > Additionally to connect to an EPP server you will need some sort of client > credentials and a form of client certificate pinning which is usually > negotiated and exchanged out-of-band. > > I am curious to understand the reasoning behind this need > > Best regards, > > Francisco > >> On 19 Mar 2024, at 19:11, Hollenbeck, Scott wrote: >> >> As noted during this morning’s regext session, we need to consider how a >> client can discover the transport services provided by an EPP server. >> Opportunistic probing is one method, another is server capability >> publication using something like an SVCB record that’s published in a DNS >> zone maintained by the EPP server operator. Perhaps something like this: >> >> epp.example.net. 7200 IN SVCB 3 epp.example.net. ( >> >>alpn="bar" port="700" transport="tcp") >> >> There is no “transport” SvcParamKey currently registered with IANA, but >> that’s easy to do. I think there’s a draft here that needs to be written. >> >> Scott > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP Transport Service Discovery
> On Mar 20, 2024, at 08:50, Jim Reid wrote: >> On 20 Mar 2024, at 07:04, Bill Woodcock wrote: >> Yes, because the registry can improve over time, and the registrars can >> update their software over time. If we don’t give updated client-side >> software a mechanism to discover that the server now supports improved >> transport, we get gridlock. > Bill, I somehow doubt a registry would introduce an updated/new transport and > not tell anyone about that. So? “Telling people about it” doesn’t get them to upgrade. If we want to improve things, we actually need to improve things, not just talk about it. -Bill signature.asc Description: Message signed with OpenPGP ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Security Lock anyone? (Was: Preliminary agenda for Prague, and call for agenda items)
We’d be _very interested_ in seeing a standardized, end-to-end registry-locking model. Specifically, one in which the registrant signs change requests, and the registry validates the signatures, and nobody in the registrar path is involved in any way. Lack of end-to-end protection was one of the key weaknesses attacked in this campaign. We had “registrar lock” enabled prior to the attack (but it was inapplicable); we went through the “registry lock” process after the attack had already begun, and we were very, very unimpressed. As currently implemented, it would not have successfully defended against the attack, since it involves both shared secrets and registrar-registry trust, which were both compromised. Neither is necessary, both weaken the security of the process. -Bill > On Feb 24, 2019, at 23:26, Alexander Mayrhofer > wrote: > > Antoin, all, > > for now this is more a question / request to the group, rather than a > specific agenda slot request – but: > > In the light of the recent attacks on registration interfaces, do we want to > take a fresh look at standardization of “Registry Lock” / “Security Lock”. > There’s some previous work on this topic (see > https://tools.ietf.org/html/draft-wallstrom-epp-registrant-problem-statement-00). > As Patrick pointed out, there’s also some IPR considerations in this area > (See his blog post at > http://www.circleid.com/posts/20150603_registry_lock_or_epp_with_two_factor_authentication/). > > I constantly hear from registrars that “Security Lock” (our product name) > would be much more attractive if there wasn’t a myriad of different processes > at each registry – so my take is that there’s room for standardization (which > probably goes beyond the pure EPP extension). I’m also hearing some fellow > ccTLD colleages are interesting in a common “profile”. > Would regext be the right spot for such a discussion? If yes, would it be > interesting to hold a 20 minutes slot in Prague? Or even a Bar-BoF before we > “report back” to the working group? > > Best, > Alex > > > Von: regext Im Auftrag von Antoin Verschuren > Gesendet: Sonntag, 24. Februar 2019 14:43 > An: Registration Protocols Extensions > Betreff: [regext] Preliminary agenda for Prague, and call for agenda items > > Hi all, > > Please find the preliminary agenda for Prague attached. > I hope I captured everyone that has requested time to speak. If not, let the > chairs know. > We still have a little bit of time left on the agenda, so if you have urgent > agenda items, let us know as well. > If you are on the agenda, start preparing ;-) > > > > > > Regards, Jim and Antoin > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt
> On Apr 8, 2021, at 10:04 AM, Quoc@registry.godaddy wrote: > I want to note as well that the "domain registry" and "DNS" aren't > necessarily the same system as a TLD may not use the DNS service of the RSP > or the RSP may not offer a DNS hosting for the TLD. Yes, that’s correct. Each TLD will have one “domain registry” which may be internal to its administrative controller or may be outsourced to an RSP; and they will have one or more, but typically several, DNS operators, which may or may not include a DNS service of the RSP. So, as Quoc notes, these are not coupled functions in any way. -Bill signature.asc Description: Message signed with OpenPGP ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
