[gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)
Sam Lanfranco
sam at lanfranco.net
Thu Dec 8 17:17:38 UTC 2016
I would draw a parallel between registry expiration dates and automobile
insurance expiration dates. Only the insurance company and the insured
know the expiry date, and in this case the LEA have the right to ask for
proof of valid insurance. A parallel practice within the
registrar/registry context would be no public information about either
when registered or expiry date, but either an annual email to
registrants (I get enough as it is trying to up sell me additional
registrar services) or a couple of reminder emails prior to the expiry
date.
That, or a similar scheme, would allow the registrant to be keep
informed - a service frequently not there now. It would also prevent the
deceptive scam marketing emails that are thinly disguised "renewal"
invoices and notices that are really registrar transfer notices or
attempts to sell "related" domain names.
Data that the registry and the registrant need for business should be
shared between them, and nobody else. Let LEA use the laws for access
(even if the laws are getting looser and looser <= another problem).
Privacy services for the contact email would prevent the questionable
value-added services offered for my domain names. I leave some WhoIS
data public to toll for the scams that are out there, and there are a
lot. A less knowledgeable domain name holder could be fleeced
substantial sums for unwanted services, and a knowledgeable domain name
holder could receive substantial spam email.
Sam L NPOC/csih
On 12/8/2016 11:58 AM, Volker Greimann wrote:
> Hi Greg,
>
> I am not disputing that, however does that information _really_ have
> to be public? In the past, the registry expiration dates even served
> to confuse the registrants due to the renew grace renewals performed
> by registries even though the registrar could still delete.
>
> Expiration dates can always be checked at your registrar.
>
> While they make registering domains on the drop easier, I am often
> hearing people complain that this service actually seen as a bad thing
> by some.
>
> I agree that created dates help determining trustworthyness, but that
> could be replaced by a domain freshness gauge, trusted certificates
> and other alternatives that would not give an exact date. Surely for
> consumer trust concerns, it is mostly irrelevant if a domain was
> registered four or five years ago and on which date?
>
> Transfer Status: That entirely depends on the mechanisms put in place
> by the registrar for removal. Some require two-factor authentification
> for this so even if someone got access to your registrar or mail
> account, he would not be able to transfer any domains out.
>
> I am not saying this data should be hidden, but I can imagine
> scenarios where it would not be needed. So we better make sure that
> when we say certain date is needed, that statement is correct.
>
> Volker
>
>
>
> Am 08.12.2016 um 17:30 schrieb Greg Aaron:
>> Expiration dates allow registrants to see when their names are
>> expiring; a domain management task.
>> Expiration dates make the domain name secondary market possible.
>> Many parties use and benefit from the secondary market, including
>> registrants, registrars, and registries.
>> Create dates are important for assigning reputation to domain names
>> and protecting consumers and Internet users.
>> So those are some benefits that IMHO outweigh speculative security
>> worries.
>>
>> Domains are often hijacked when the attacker gains control of the
>> registrant account. And that allows the attacker to remove
>> clientTransferProhibited status. So the status does not even matter.
>>
>> Every tool can be misused if someone tries hard enough. Domain
>> names enable lots of crime. Is the response to that problem to make
>> domain names very difficult and expensive to register? Or is making
>> registration information available one proportional and reasonable
>> response to the problem?
>>
>> All best,
>> --Greg
>>
>>
>>
>> -----Original Message-----
>> From: gnso-rds-pdp-wg-bounces at icann.org
>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
>> Sent: Thursday, December 8, 2016 10:56 AM
>> To: gnso-rds-pdp-wg at icann.org
>> Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data
>> (was Re: key concepts: say "contact data" when that is what we mean)
>>
>> Near the expiration dates, phony renewal notices are usually sent.
>> Publishing the dates of creation or expiration makes calculating that
>> easier.
>>
>> As for the status fields, I am guessing criminals would be able to
>> deduce which domains are easier to steal if they can see which ones
>> have a transfer lock enabled?
>>
>> Volker
>>
>>
>>
>> Am 08.12.2016 um 16:28 schrieb Greg Aaron:
>>> Dear Rob:
>>>
>>> How does showing a domain's status fields "increase the 'criminal
>>> activity' regarding a domain name"? How does showing a domain's
>>> create and expiration dates "increase abuse/malicious activity"?
>>>
>>> As someone who's studied the criminal use of domains for many years,
>>> I have never seen or heard of any evidence of that. In fact, domain
>>> status and date information is important to people who investigate
>>> abuse or many want to make judgements about the trustworthiness of a
>>> domain.
>>>
>>> Best,
>>> --Greg
>>>
>>>
>>> -----Original Message-----
>>> From: gnso-rds-pdp-wg-bounces at icann.org
>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Rob Golding
>>> Sent: Wednesday, December 7, 2016 8:42 PM
>>> To: gnso-rds-pdp-wg at icann.org
>>> Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data
>>> (was Re: key concepts: say "contact data" when that is what we mean)
>>>
>>>>> the domain name,
>>>>> the sponsoring registrar name
>>>>> and ID,
>>> are not controversial to me
>>>
>>>>> the domain's status(es) ,
>>>> One could argue that this data should not be included because most of
>>>> it is not directly relevant to whether a domain name ought to be
>>>> working. (For instance, whether an update is pending is not
>>>> necessarily relevant to whether a name ought to resolve on the
>>>> Internet right now.) Moreover, one could argue that at least some
>>>> status values radiate information about what a registrant may have
>>>> done, and also potentially supports attempts to game the registration
>>>> system to obtain a domain name contrary to the interests of the
>>>> previous registrant.
>>> Showing the status certainly increases the "criminal activity"
>>> regarding a domain name, and is a good reason not to include it.
>>>
>>>>> created- [date]
>>>>> updated- [date]
>>>>> expiration date[s]
>>> Lots of pros and cons for the dates - showing them increases
>>> abuse/malicious activity, allows for more social engineering, but
>>> they are useful.
>>>
>>> The downside is (as a Registar) we have more than once had phone calls
>>> along the lines of
>>>
>>> Caller: "Hi, I unlocked my domain yesterday and got the epp code,
>>> but I forgot to write it down and dont have the email with me today,
>>> can you just read it out please"
>>> Us: "Who are you ?"
>>> Caller: "I'm (blah) working with (reads out name of registrant from
>>> whois)" // "I'm (name of registrant)"
>>> Us: "The account holder can get the details if needed from the
>>> client system"
>>> Caller: then usually tries some other tactic else hangs up or gets
>>> abusive - often tries to play the greed card "i'll take all my
>>> bisiness away and i know lots of your other customers"
>>> Us: *click*
>>>
>>>
>>>>> nameservers.
>>> And their IP addresses if self-referencing
>>>
>>>> Moreover, in principle if the
>>>> registry and DNS are in harmony this data is already public, so there
>>>> is no harm in including it in another public repository.
>>> The 'harm' being :
>>> duplication = bad
>>> duplication = discrepancies
>>> duplication = mistakes
>>> as a general rule
>>>
>>>> It is hard for me to come up with an argument why this should not be
>>>> public except for the case where someone thinks the RDDS is a bad
>>>> idea in general.
>>> The argument is that we're now getting RDS to deviate from "accurate"
>>> into "they might be the nameservers, but they might not, and even if
>>> they they were 30 minutes ago, they might not be anymore, I'm RDS
>>> not a shovel" responses.
>>>
>>> Do the NS and IP data help troubleshoot ? As they're neither
>>> authoritive nor necessarily reliable I doubt it, unless you dont
>>> know how to actually get the authoritive data, in which case what
>>> exactly are you able to troubleshoot ?
>>>
>>> Other data elements _currently_ required
>>> - I suggest we make this a new "group" as they're not "domain data"
>>> and they're not "registrant data"
>>>
>>>
>>> Registry Domain ID:
>>> Registrar Abuse Contact Email:
>>> Registrar Abuse Contact Phone:
>>> Reseller:
>>> DNSSEC:
>>>
>>>
>>> Rob
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>> --
>> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>>
>> Mit freundlichen Grüßen,
>>
>> Volker A. Greimann
>> - Rechtsabteilung -
>>
>> Key-Systems GmbH
>> Im Oberen Werk 1
>> 66386 St. Ingbert
>> Tel.: +49 (0) 6894 - 9396 901
>> Fax.: +49 (0) 6894 - 9396 851
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com
>> / www.BrandShelter.com
>>
>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>> www.facebook.com/KeySystems
>> www.twitter.com/key_systems
>>
>> Geschäftsführer: Alexander Siffrin
>> Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.:
>> DE211006534
>>
>> Member of the KEYDRIVE GROUP
>> www.keydrive.lu
>>
>> Der Inhalt dieser Nachricht ist vertraulich und nur für den
>> angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe,
>> Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist
>> unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so
>> bitten wir Sie, sich mit uns per E-Mail oder telefonisch in
>> Verbindung zu setzen.
>>
>> --------------------------------------------
>>
>> Should you have any further questions, please do not hesitate to
>> contact us.
>>
>> Best regards,
>>
>> Volker A. Greimann
>> - legal department -
>>
>> Key-Systems GmbH
>> Im Oberen Werk 1
>> 66386 St. Ingbert
>> Tel.: +49 (0) 6894 - 9396 901
>> Fax.: +49 (0) 6894 - 9396 851
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com
>> / www.BrandShelter.com
>>
>> Follow us on Twitter or join our fan community on Facebook and stay
>> updated:
>> www.facebook.com/KeySystems
>> www.twitter.com/key_systems
>>
>> CEO: Alexander Siffrin
>> Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
>>
>> Member of the KEYDRIVE GROUP
>> www.keydrive.lu
>>
>> This e-mail and its attachments is intended only for the person to
>> whom it is addressed. Furthermore it is not permitted to publish any
>> content of this email. You must not use, disclose, copy, print or
>> rely on this e-mail. If an addressing or transmission error has
>> misdirected this e-mail, kindly notify the author by replying to this
>> e-mail or contacting us by telephone.
>>
>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
--
------------------------------------------------
"It is a disgrace to be rich and honoured
in an unjust state" -Confucius
邦有道，贫且贱焉，耻也。邦无道，富且贵焉，耻也
------------------------------------------------
Dr Sam Lanfranco (Prof Emeritus & Senior Scholar)
Econ, York U., Toronto, Ontario, CANADA - M3J 1P3
email: Lanfran at Yorku.ca Skype: slanfranco
blog: https://samlanfranco.blogspot.com
Phone: +1 613-476-0429 cell: +1 416-816-2852
More information about the gnso-rds-pdp-wg
mailing list