[gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)

Thu Dec 8 19:41:59 UTC 2016

On 8 Dec 2016, at 11:30, Greg Aaron wrote:

> 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.

I want to push back a little bit on some of these, primarily because I 
want to be careful about the precedent we’re setting.

I think that expiration date and registrants is an issue for the 
registrant to resolve with their “registrar”.  It is probably 
information that the registry has and as such the registry could publish 
it, assuming the registry has a publication system (see what I did 
there?), but why transfer that burden?  Wouldn’t registrars prefer to 
strengthen their relationship with a registrant?

I believe we need to be careful about the secondary market argument.  
That argument assumes facts not in evidence, i.e., this is how it works 
today and therefore it should continue to work that way.  We need 
another reason than just the secondary market.  The problem is, if the 
secondary market is a justification for this data, then what data would 
not be justified by the secondary market?

While I agree that create dates are a leading indicator of domain 
reputation, I know that you also know this is trivial to game if a 
malefactor were so inclined.  So, there might be a “security 
argument” that could be made about create dates but I’m not sure I 
would celebrate that fact, i.e., I’m reserving my opinion on whether 
or not that is compelling.

Jim

>
> 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
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg