[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access

Wed May 31 13:38:13 UTC 2017

Speaking as someone who deals with anti-fraud and anti-abuse for a group of
websites, we find a very high correlation between fraud/abuse and new
account setups from newly created domains. John is correct that creation
date is widely used by security and anti-abuse teams.

Michael Hammer

On Wed, May 31, 2017 at 9:28 AM, Volker Greimann <vgreimann at key-systems.net>
wrote:

> So if I register a new domain and immediately start using it as my new
> private email address, you would immediately consider that suspicious?
> Because I just did that a few months ago because my old address overflowed
> with spam...
>
> Many end-customers (normal people) also immediately operationalize their
> domains because they do not register it to use it later but rather because
> they have an immediate need for it.
>
> I think you are generalizing too much...
>
> Best,
>
> Volker
>
>
>
> Am 31.05.2017 um 15:07 schrieb John Bambenek via gnso-rds-pdp-wg:
>
>> And creation date is used by security as a hugely valuable indicator of
>> suspiciousness. Domain gets registered and starts sending mail immediately?
>> Obviously spam or malicious. Criminals immediately operationalize their
>> domains. Normal people don't. If we want to weigh the harms, I think having
>> that date prevents a lot more problems than the ones you mention that can
>> largely be solved by a mediocre spam filter.
>>
>> Sent from my iPhone
>>
>> On May 31, 2017, at 01:33, Rob Golding <rob.golding at astutium.com> wrote:
>>
>> Revoking that data can't stop brute force transfer attempts,
>>>>
>>> If the status is Transfer Prohibited, then yes it does, as they are
>>> automatically failed by the registry when the gaining registrar sends them.
>>>
>>> It's not about whether a domain needs a status, but whether that status
>>> should be "open to the public" rather than restricted to those who need it
>>> (registrant via their registrar, authenticated users for specific use
>>> cases, etc)
>>>
>>> Registrars sell domains in precisely 1 year blocks
>>>> of time.
>>>>
>>> one-or-more periods of years for most gTLDs, with 2,1,5 being the most
>>> common at my registrar (in that order)
>>>
>>> Creation date I left off, although it's easy to work out from the
>>> changes to the zone files
>>>
>>> Creation date does (in conjunction with the other data) get abused -
>>> I've had over 30 "contacts" from people trying to sell me seo, websites,
>>> stationary since registering a variation spelling of a domain on the 19th
>>> May (to help those who keep missing out the final "S" when sending an email
>>> to me from getting bounces) - 11pm on Monday from an Asian callcentre using
>>> a UK voip number (now reported to the TPS) being one of the most intrusive
>>> this week.
>>>
>>> Whilst I can't stop the free pens, adwords vouchers, brochures for
>>> radiator valves and other tat coming through the letterbox based on a
>>> domain registration, I've even seen _registrars_ doing it :(
>>>
>>> I didn't forget, but excluded Updated date - in my experience it's wrong
>>> at least as much as it's correct -  and my opinion is that data you can't
>>> trust does more harm than good
>>>
>>>  From 2 of my domains:
>>> 1. Updated Date: 2017-04-11T23:15:07.0Z
>>> is correct, as that is when I renewed it
>>>
>>> 2. Updated Date: 2016-01-09T22:25:53Z
>>> is not correct as I changed the nameservers in Dec
>>>
>>> To me it looks like it only changes the "updated date" when the _dates_
>>> on a domain change, not on other types of updates.
>>>
>>> I actually like the idea of revoking all nameserver data. I like that
>>>> idea the more and more I think about it.
>>>>
>>> NS information is redundant in "whois", and depending on which whois
>>> server/system you ask, regularly incorrect - there are a variety of reasons
>>> for this, including but not limited to:
>>> * registrars don't tidy up
>>> * registries aren't realtime
>>> * 3rd-party systems cache the data
>>> * end-users dont know the difference between whois (service) and "whois"
>>> being in the name of a website
>>> and so on
>>> I've seen domains where Directi WHOIS has said one thing, a Whois
>>> website has said another and the actual nameservers were different to both
>>> of those on the domain at the registry (plus the actual issue I was
>>> diagnosing was that the zone slaved the nameservers off to yet different
>>> ns, which is why the A record the client thought should be returned wasn't
>>> the IP they were seeing)
>>>
>>> Use the right tools for the job, and in the case of DNS that's *NOT*
>>> whois - we'd be doing a global service to the internet by taking them out
>>> of it.
>>>
>>> SOA data is almost always garbage. 95% of the time I find it useless.
>>>>
>>> With DNS Zones being mostly automated by hosting control panels, it's
>>> "variable" as to what goes in there, and SOAs rarely get updated once
>>> created beyond the serial changing, so sadly yes, it's of limited use now
>>>
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170531/4d8ee98f/attachment-0001.html>