gtld-tech URS technical requeriments
Colleagues, Attached you will find a draft version of the URS technical requirements. You can find more information of how URS works here: http://newgtlds.icann.org/en/applicants/urs/rules-28jun13-en.pdf The AGB provides high-level requirements regarding the URS procedures; the objective of the attached document is to define the detailed technical requirements for Registries and Registrars. Another document with the technical requirements for the URS provider is going to be published soon, but right now we want to obtain feedback regarding the requirements for Registries and Registrars. Please provide your feedback no later than Tuesday 23 of July. If you are going to be in Durban, send me an email and we can arrange an informal discussion about this. Regards, Gustavo
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this. Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld. Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in. R's, John
Let me ask the dumb question....do we really need a set of standard specs for this for a registry? ----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this. Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld. Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in. R's, John
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more. The basic problem is that the Internet is not synonymous with web servers, but too many people forget that. R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
hi all, a few questions: - is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture? - when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right? - is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state? if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting. mikey On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
With all due respect, most of the registries that have been planning on actually launching at some point this year I would venture to say have either already built their functionality to do this or are otherwise planning to do this manually, both of which are acceptable options. We have pretty much known the rules now from the Guidebook for months - dare I say years for this. I am not sure who asked for a "standard" to be developed on this, but this is WAY too late in the game for icann to expect any registry to move to this new "standard" at this point in time. So I will ask the dumb question again...do we really need this? My question Sent from my iPad On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike@haven2.com> wrote:
hi all,
a few questions:
- is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture?
- when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right?
- is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state?
if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting.
mikey
On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
Do we need this? Yes. A standard/specification is required if there is to be a consistent implementation across all registries. Seeking an update on URS technical/process issues was on our agenda for Durban - instead we can now discuss moving this forward (in whatever direction that may be). Thanks to Gustavo for getting this document out, and the discussion rolling. Regards, James Mitchell / Product Owner ARI Registry Services
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Neuman, Jeff Sent: Tuesday, 9 July 2013 11:07 AM To: Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
With all due respect, most of the registries that have been planning on actually launching at some point this year I would venture to say have either already built their functionality to do this or are otherwise planning to do this manually, both of which are acceptable options. We have pretty much known the rules now from the Guidebook for months - dare I say years for this.
I am not sure who asked for a "standard" to be developed on this, but this is WAY too late in the game for icann to expect any registry to move to this new "standard" at this point in time.
So I will ask the dumb question again...do we really need this?
My question
Sent from my iPad
On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike@haven2.com> wrote:
hi all,
a few questions:
- is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture?
- when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right?
- is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state?
if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting.
mikey
On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
I guess my point in this is that we should be concerned with the "what" are registries and registrars supposed to do as opposed to the "how". And from my re-reading of the AGB, it seems like that document for the most part does an ok job in that. ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....." The whole thing just seems unnecessarily prescriptive to me. Frankly I would rather ICANN be spending its time worrying about getting up the testing environment with the TMCH than with this, but that may just be me. Jeffrey J. Neuman Neustar, Inc. / Vice President, Business Affairs -----Original Message----- From: James Mitchell [mailto:james.mitchell@ausregistry.com.au] Sent: Monday, July 08, 2013 11:15 PM To: Neuman, Jeff; Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: RE: [gtld-tech] gtld-tech URS technical requeriments Do we need this? Yes. A standard/specification is required if there is to be a consistent implementation across all registries. Seeking an update on URS technical/process issues was on our agenda for Durban - instead we can now discuss moving this forward (in whatever direction that may be). Thanks to Gustavo for getting this document out, and the discussion rolling. Regards, James Mitchell / Product Owner ARI Registry Services
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Neuman, Jeff Sent: Tuesday, 9 July 2013 11:07 AM To: Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
With all due respect, most of the registries that have been planning on actually launching at some point this year I would venture to say have either already built their functionality to do this or are otherwise planning to do this manually, both of which are acceptable options. We have pretty much known the rules now from the Guidebook for months - dare I say years for this.
I am not sure who asked for a "standard" to be developed on this, but this is WAY too late in the game for icann to expect any registry to move to this new "standard" at this point in time.
So I will ask the dumb question again...do we really need this?
My question
Sent from my iPad
On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike@haven2.com> wrote:
hi all,
a few questions:
- is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture?
- when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right?
- is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state?
if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting.
mikey
On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....."
What are you going to do when sleazy domainers start phishing you with fake messages from URS providers saying to turn their domains back on? While I agree that it's silly to try and define all of the low level details, I don't think it's silly to give some thought to security issues like how the URS providers and registries recognize each other. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.
John,
Betreff: Re: [gtld-tech] gtld-tech URS technical requeriments
ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....."
What are you going to do when sleazy domainers start phishing you with fake messages from URS providers saying to turn their domains back on?
While I agree that it's silly to try and define all of the low level details, I don't think it's silly to give some thought to security issues like how the URS providers and registries recognize each other.
almost a serious question. What about a PKI/Web-Of-Trust, managed by the URS provider instead of S/MIME? But at least I think it is too complex to manage and may delay the URS implementation/process. Matthias Pfeifer - dotVersicherung
DNSSEC is already a foundation for PKI and it's a mandated requirement for new gTLDs. While DANE for SMTP is not ready for prime time, we could provisionally have only URS provider sign e-mail with S/MIME and include a random token in the subject there needs to be in the answer for recognition: From: URS Provider Subject: Suspension of xxxx.gtld , token 1234567890 Signed: URS Provider (S/MIME) From: Registry: Subject: Re: Suspension of xxxx.gtld , token 1234567890 (not required to be signed) 18 months from now, signing with DANE will likely be feasible to be a requirement to both URS Provider and registry. This way we also keeps authentication inside the DNS system and foster the roll-out of security measures. Rubens On Jul 10, 2013, at 11:37 AM, "Matthias Pfeifer" <info@freshmail.de> wrote:
John,
Betreff: Re: [gtld-tech] gtld-tech URS technical requeriments
ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....."
What are you going to do when sleazy domainers start phishing you with fake messages from URS providers saying to turn their domains back on?
While I agree that it's silly to try and define all of the low level details, I don't think it's silly to give some thought to security issues like how the URS providers and registries recognize each other.
almost a serious question.
What about a PKI/Web-Of-Trust, managed by the URS provider instead of S/MIME?
But at least I think it is too complex to manage and may delay the URS implementation/process.
Matthias Pfeifer - dotVersicherung
What about a PKI/Web-Of-Trust, managed by the URS provider instead of S/MIME?
+1 - PGP should also be an option here. G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
Are we way overthinking this? How does it work today when UDRP providers notify registrars about UDRP proceedings? And have there been any reported issues with registrants spoofing WIPO or any of the other providers. if the answer is no, then lets drop this thread for now and focus on a testing environment for the TMCH. If the answer is yes, then lets address quickly and move on. thanks. Jeffrey J. Neuman Neustar, Inc. / Vice President, Business Affairs -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gavin Brown Sent: Wednesday, July 10, 2013 10:49 AM To: Matthias Pfeifer Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
What about a PKI/Web-Of-Trust, managed by the URS provider instead of S/MIME?
+1 - PGP should also be an option here. G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
If this is a technical requirements, is it necessary to include the part of section 4? PGP +1
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Eric Brunner-Williams Sent: Wednesday, July 10, 2013 11:06 PM To: gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
On 7/10/13 7:48 AM, Gavin Brown wrote:
What about a PKI/Web-Of-Trust, managed by the URS provider instead of
S/MIME? +1 - PGP should also be an option here.
+2
PGP +1 Linlin Zhou <zhoulinlin@cnnic.cn> wrote:
If this is a technical requirements, is it necessary to include the part of section 4?
PGP +1
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Eric Brunner-Williams Sent: Wednesday, July 10, 2013 11:06 PM To: gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
On 7/10/13 7:48 AM, Gavin Brown wrote:
What about a PKI/Web-Of-Trust, managed by the URS provider instead of
S/MIME? +1 - PGP should also be an option here.
+2
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Dear Gustavo: I will ask the question a different way. It is called a "technical requirements" document. Will ICANN consider the contents of this document to be binding upon new registry operators? Is the purpose of the document to mandate exact requirements that every operator must follow? That is what it seems like to me. If the document has a different goal please let us know. With best wishes, --Greg -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Neuman, Jeff Sent: Tuesday, July 09, 2013 9:08 AM To: 'James Mitchell'; Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments I guess my point in this is that we should be concerned with the "what" are registries and registrars supposed to do as opposed to the "how". And from my re-reading of the AGB, it seems like that document for the most part does an ok job in that. ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....." The whole thing just seems unnecessarily prescriptive to me. Frankly I would rather ICANN be spending its time worrying about getting up the testing environment with the TMCH than with this, but that may just be me. Jeffrey J. Neuman Neustar, Inc. / Vice President, Business Affairs -----Original Message----- From: James Mitchell [mailto:james.mitchell@ausregistry.com.au] Sent: Monday, July 08, 2013 11:15 PM To: Neuman, Jeff; Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: RE: [gtld-tech] gtld-tech URS technical requeriments Do we need this? Yes. A standard/specification is required if there is to be a consistent implementation across all registries. Seeking an update on URS technical/process issues was on our agenda for Durban - instead we can now discuss moving this forward (in whatever direction that may be). Thanks to Gustavo for getting this document out, and the discussion rolling. Regards, James Mitchell / Product Owner ARI Registry Services
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Neuman, Jeff Sent: Tuesday, 9 July 2013 11:07 AM To: Mike O'Connor Cc: John R.Levine; gtld-tech@icann.org Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
With all due respect, most of the registries that have been planning on actually launching at some point this year I would venture to say have either already built their functionality to do this or are otherwise planning to do this manually, both of which are acceptable options. We have pretty much known the rules now from the Guidebook for months - dare I say years for this.
I am not sure who asked for a "standard" to be developed on this, but this is WAY too late in the game for icann to expect any registry to move to this new "standard" at this point in time.
So I will ask the dumb question again...do we really need this?
My question
Sent from my iPad
On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike@haven2.com> wrote:
hi all,
a few questions:
- is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture?
- when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right?
- is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state?
if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting.
mikey
On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
No-one with more than half-a-clue has ever assumed web == internet, and in reality web is an insignificant part of the internet ... Based on a simple protocol analysis of ~30Gb/s of transit, web/http/https is *under 4%* of "internet traffic". Rob
In article <06cebd900849932587de9a6a73f17771@astutium.com> you write:
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
No-one with more than half-a-clue has ever assumed web == internet, and in reality web is an insignificant part of the internet ... Based on a simple protocol analysis of ~30Gb/s of transit, web/http/https is *under 4%* of "internet traffic".
No kidding. So it does seem odd that the redirection draft only refers to http, doesn't it?
Well, Yes and no. Most people will think of the Internet as the web, and it has nothing to do with traffic. Most people don't know that e-mail is a protocol, they get their email from the web, so why would they care? But in the strict sense, yes…. In fact, how would registries deal with HTTPS connections and certificates? or should we be ONLY serving a URS page on top of HTTP? francisco On Jul 8, 2013, at 9:07 PM, rob.golding@astutium.com wrote:
No-one with more than half-a-clue has ever assumed web == internet, and in reality web is an insignificant part of the internet ... Based on a simple protocol analysis of ~30Gb/s of transit, web/http/https is *under 4%* of "internet traffic".
Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
Thank you John, please send your feedback directly to this list. Regarding email, the current idea is that the NSs for URS locking provided by the URS provider, reply with MX 0 . when queried for the MX of a URS locked domain name. The host in the * IN A/AAAA will only answer requests on TCP/80. The TTL in the reply from the URS provider NSs will be short to accommodate the case in which the original NSs are restored. Obivously, this solution do not consider protocols other than HTTP and SMTP. The high level requirements for URS are described in the AGB (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf) , pp. 299-309. Regards, Gustavo On 7/8/13 3:29 PM, "John R. Levine" <johnl@iecc.com> wrote:
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regarding email, the current idea is that the NSs for URS locking provided by the URS provider, reply with MX 0 . when queried for the MX of a URS locked domain name.
That would help, but since MX 0 . is not formally standardized* there's some other stuff that would help more. If I may ask a meta-question, who's writing on this spec, and who's providing technical and security advice? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly * - utterly by coincidence, I resuscitated a 2006 draft about it last week to see if the IETF application area wants to do something about it
Thank you John, Comments inline. Regards, Gustavo On 7/8/13 4:54 PM, "John R. Levine" <johnl@iecc.com> wrote:
Regarding email, the current idea is that the NSs for URS locking provided by the URS provider, reply with MX 0 . when queried for the MX of a URS locked domain name.
That would help, but since MX 0 . is not formally standardized* there's some other stuff that would help more.
GL - There are several ideas floating around regarding the technical requirements of the URS provider, if you want to provide feedback, you can send it to the list or to me. We appreciate your feedback. The MX 0 . approach appears to be well supported in MTAs (even if not formal standardized) and should be easy to implement and maintain from the URS provider perspective.
If I may ask a meta-question, who's writing on this spec, and who's providing technical and security advice?
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
* - utterly by coincidence, I resuscitated a 2006 draft about it last week to see if the IETF application area wants to do something about it
On 09/07/13 01:29, Gustavo Lozano wrote: [snip]
GL - There are several ideas floating around regarding the technical requirements of the URS provider, if you want to provide feedback, you can send it to the list or to me.
We appreciate your feedback.
The MX 0 . approach appears to be well supported in MTAs (even if not formal standardized) and should be easy to implement and maintain from the URS provider perspective.
Since the kinds of people who typo squat probably don't care about setting up MTAs properly, and probably care less for standards; how do we prevent them abusing partitions, slow networks, and/or high pre-URS TTLs to "guide" emails to their servers that don't/won't respect a lower level MX record? Wouldn't it be easy enough for the typo squatters to "pre-cache" the MX / A records on major ISP's recursive servers at the time of registration with very high TTLs to circumvent this strategy? Matt -- Matt Keenan CTO TLD Assets LLC Tel +44 77 3787 1919 UK Los Angeles Warner Center , Ste 400 , 21700 Oxnard St. Woodland Hills , CA 91367 Tel + 310 650 2804 The person sending this message is an employee of TLD Assets, LLC (TLDA). This message, including any attachments, may contain confidential, proprietary, legally-privileged information or information that is exempt from disclosure under applicable law and is intended solely for the use of the addressee named above. No confidentiality or privilege is waived or lost by any misdirected transmission. If you are not the intended recipient of this message you must not disseminate, distribute, copy or take any action in reliance on this e-mail or any attachment. Please notify the sender immediately and please delete it from your system. This communication is for information purposes only and should not be regarded as an offer, solicitation or recommendation to sell or purchase any security or other financial product. All information contained in this communication is not warranted as to completeness or accuracy and is subject to change without notice. TLDA, including its affiliates, does not guarantee that the integrity of this communication has been maintained, or that this communication is free of viruses, interceptions or interference. TLD Assets, including its affiliates does not accept liability for any errors or omissions arising as a result of this transmission, or for any delay in its receipt or damage to your system. Furthermore, all incoming and outgoing e-mail of TLDA is subject to review by its Legal/Compliance Department. As part of the compliance and surveillance of TLDA's business activities, this message may be read by persons other than the intended recipients. TLDA, including its affiliates, reserves the right to archive all electronic communications through its network.
I was going to answer the question, but never mind. R's, John
The person sending this message is an employee of TLD Assets, LLC (TLDA). This message, including any attachments, may contain confidential, proprietary, legally-privileged information or information that is exempt from disclosure under applicable law and is intended solely for the use of the addressee named above. No confidentiality or privilege is waived or lost by any misdirected transmission. If you are not the intended recipient of this message you must not disseminate, distribute, copy or + take any action in reliance on this e-mail or any attachment. Please notify the sender immediately and please delete it from your system.
This communication is for information purposes only and should not be regarded as an offer, solicitation or recommendation to sell or purchase any security or other financial product. All information contained in this communication is not warranted as to completeness or accuracy and is subject to change without notice.
TLDA, including its affiliates, does not guarantee that the integrity of this communication has been maintained, or that this communication is free of viruses, interceptions or interference. TLD Assets, including its affiliates does not accept liability for any errors or omissions arising as a result of this transmission, or for any delay in its receipt or damage to your system.
Furthermore, all incoming and outgoing e-mail of TLDA is subject to review by its Legal/Compliance Department. As part of the compliance and surveillance of TLDA's business activities, this message may be read by persons other than the intended recipients. TLDA, including its affiliates, reserves the right to archive all electronic communications through its network.
Since the kinds of people who typo squat probably don't care about setting up MTAs properly, and probably care less for standards; how do we prevent them abusing partitions, slow networks, and/or high pre-URS TTLs to "guide" emails to their servers that don't/won't respect a lower level MX record? Wouldn't it be easy enough for the typo squatters to "pre-cache" the MX / A records on major ISP's recursive servers at the time of registration with very high TTLs to circumvent this strategy?
Actually, I've never seen typosquats doing anything with mail other than perhaps setting up a mail server to collect inquiries from buyers and one odd startup that wants to monetize bounce messages. (Don't ask.) The problem is more subtle. As brands have gotten better at authenticating their real mail, it's gotten much harder to get a phish delivered with a return address like security@paypal.com. So instead they use lookalike domains, e.g., security@paypaI.tld, or security@paypal-validation.tld. That's much harder to defend against since it's effectively impossible to mechanically identify names that look like other names in a fraudulent way. So what you want to do when you suspend a typosquat is to publish as clearly as possible that this isn't a valid mail domain. A null MX record is part of it, but you also need SPF, DMARC, and some other stuff. ICANN's proposing a wildcard to catch *.whatever.tld, which makes things harder but not impossibly so. The point of this rant is that if ICANN or whoever is going to design this, they need help from people who are more familiar with the security issues, who can tell them what they need to specify and what they don't need to bother with. R's, John
Hello! Thanks for bringing up this discussion.
The host in the * IN A/AAAA will only answer requests on TCP/80.
The TTL in the reply from the URS provider NSs will be short to accommodate the case in which the original NSs are restored.
Obivously, this solution do not consider protocols other than HTTP and SMTP.
Are there any other (other that here: http://newgtlds.icann.org/en/applicants/urs) written documents or drafts where is discussed how to handle locked domain names (MX=0, only 80/25 as open ports, etc)? Thank you! Matthias Pfeifer IT-Consulting // .versicherung
-----Ursprüngliche Nachricht----- Von: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Gustavo Lozano Gesendet: Dienstag, 9. Juli 2013 01:34 An: John R. Levine Cc: gtld-tech@icann.org Betreff: Re: [gtld-tech] gtld-tech URS technical requeriments
Thank you John, please send your feedback directly to this list.
Regarding email, the current idea is that the NSs for URS locking provided by the URS provider, reply with MX 0 . when queried for the MX of a URS locked domain name.
The host in the * IN A/AAAA will only answer requests on TCP/80.
The TTL in the reply from the URS provider NSs will be short to accommodate the case in which the original NSs are restored.
Obivously, this solution do not consider protocols other than HTTP and SMTP.
The high level requirements for URS are described in the AGB (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12- en.pdf) , pp. 299-309.
Regards, Gustavo
On 7/8/13 3:29 PM, "John R. Levine" <johnl@iecc.com> wrote:
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Oops. I have overseen the attached Draft from Gustavo. Sorry for the noise.
Von: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Matthias Pfeifer Gesendet: Dienstag, 9. Juli 2013 11:57 An: gtld-tech@icann.org Betreff: Re: [gtld-tech] gtld-tech URS technical requeriments
Hello!
Thanks for bringing up this discussion.
The host in the * IN A/AAAA will only answer requests on TCP/80.
The TTL in the reply from the URS provider NSs will be short to accommodate the case in which the original NSs are restored.
Obivously, this solution do not consider protocols other than HTTP and SMTP.
Are there any other (other that here: http://newgtlds.icann.org/en/applicants/urs) written documents or drafts where is discussed how to handle locked domain names (MX=0, only 80/25 as open ports, etc)?
Thank you!
Matthias Pfeifer IT-Consulting // .versicherung
-----Ursprüngliche Nachricht----- Von: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Gustavo Lozano Gesendet: Dienstag, 9. Juli 2013 01:34 An: John R. Levine Cc: gtld-tech@icann.org Betreff: Re: [gtld-tech] gtld-tech URS technical requeriments
Thank you John, please send your feedback directly to this list.
Regarding email, the current idea is that the NSs for URS locking provided by the URS provider, reply with MX 0 . when queried for the MX of a URS locked domain name.
The host in the * IN A/AAAA will only answer requests on TCP/80.
The TTL in the reply from the URS provider NSs will be short to accommodate the case in which the original NSs are restored.
Obivously, this solution do not consider protocols other than HTTP and SMTP.
The high level requirements for URS are described in the AGB (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12- en.pdf) , pp. 299-309.
Regards, Gustavo
On 7/8/13 3:29 PM, "John R. Levine" <johnl@iecc.com> wrote:
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Gustavo, Colleagues, A few meta-comments. Working with text rather than pdf is the norm for standards track specifications, and lesser documents, in the IETF. IETF documents arise from a desire by two or more implementers of the functionality to be specified to inter-operate. 2119 is a document intended for standards track documents. IETF standards track documents arise from a desire by two or more implementers of the previously specified functionality to formalize the previously specified inter-operation. Generally a series of non-normative documents precede the publication of a normative document, e.g., the publication of grrp, xrp and epp drafts prior to publication of 3730 et seq. If you could make the obvious changes to the presentation form of the text (from .pdf to ASCII, generally without the xml2rfc markup), and delete the normative specification language from a non-normative draft requirements doc, I could look past the first lines with confidence that we are using mutually understood terms, I for one would be a <registrar_hat="ON">happier camper</registrar_hat>. Eric Brunner-Williams IETF Performance Directorate
Gustavo, Thank you for posting the draft of the URS technical requirements. I would categorize the document more as a high-level approach proposal then as technical requirements. I don't believe there has been much technical discussion on URS and I recommend that you setup a conference meeting to discuss this proposal and to discuss other options to meet the requirements of URS. It is premature to cutoff discussion on July 23rd based on the lack of discussion on this list, which cannot be interpreted as acceptance. As with the TMCH, there is the need for a high level of collaboration on this to create the best technical solution. Thanks, -- JG [cid:F48D5C46-B461-4461-AF19-301157A70558] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Date: Monday, July 8, 2013 6:01 PM To: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: gtld-tech URS technical requeriments Colleagues, Attached you will find a draft version of the URS technical requirements. You can find more information of how URS works here: http://newgtlds.icann.org/en/applicants/urs/rules-28jun13-en.pdf The AGB provides high-level requirements regarding the URS procedures; the objective of the attached document is to define the detailed technical requirements for Registries and Registrars. Another document with the technical requirements for the URS provider is going to be published soon, but right now we want to obtain feedback regarding the requirements for Registries and Registrars. Please provide your feedback no later than Tuesday 23 of July. If you are going to be in Durban, send me an email and we can arrange an informal discussion about this. Regards, Gustavo
Gustavo,
Please provide your feedback no later than Tuesday 23 of July. If you are going to be in Durban, send me an email and we can arrange an informal discussion about this. Thanks for posting the document. It seems that there was no informal discussion round in Durban about this, so here are my comments:
- Re-delegating domains to an arbitrary set of nameservers (communicated in the URS case itself) seems worrying. We strongly suggest to consider the following: a) require URS providers to use a pre-defined set of nameservers per URS provider as redelegation target (rather than arbitrary hosts), and communicate those hostnames beforehand to each registry. Registry providers could then create the respective host objects before the actual URS requests. b) Registries could then also filter URS requests against that set of nameservers, and hence reduce the risk of rogue re-delegations. Such "well known" URS hosts could also give an indication regarding the status of the domain in the WHOIS. c) ICANN should also consider that the re-delegation of a domain would also affect subordinate hosts, and therefore potentially other domains that are delegated to those subordinate hosts. This is currently not addressed at all in the document. d) URS providers should never require glue changes of such subordinate host names in the process of such re-delegation. thanks Alex Mayrhofer nic.at
participants (19)
-
Alexander Mayrhofer -
Eric Brunner-Williams -
Francisco Obispo -
Gavin Brown -
Gould, James -
Greg Aaron -
Gustavo Lozano -
James Mitchell -
John Levine -
John R Levine
-
John R. Levine -
Linlin Zhou -
Luis Muñoz -
Matt Keenan -
Matthias Pfeifer -
Mike O'Connor -
Neuman, Jeff -
rob.golding＠astutium.com -
Rubens Kuhl