ICANN 71: Difference between revisions

Line 36:

====Reputation Block Lists====

This plenary was guided by the objective of helping the ICANN community understand [[RBL]]s: what they are, how they're made, what they can be used for, obstacles, and advances. Three people ([[Carel Bitter]], [[Roman Huessy]], and [[Ben Coon]]) from the RBL field were interviewed by the moderator ([[LG Forsberg]]. A cybersecurity expert from ICANN's [[OCTO]] ([[Samaneh Tajalizadehkhoob]]), the vice-chair of [[M3AAWG]] ([[Matt Thomas]]), the co-chair of ICANN's DNS Abuse working group ([[Reg Levy]]), and the co-vice chair of [[ALAC]] Joanna Kulesza also spoke.

The panel discussed:

''The panel discussed:''

* ~~whether~~ the lists are maintained through automation or by humans

* Whether the lists are maintained through automation or by humans

* ~~the~~ frequency of false positives, and the most common reasons behind them

:: The datasets are generally automated but humans spot-check URLs that don’t score high enough to be included in the RBL, add/remove them from the lists, and to verify false positives.

* The frequency of false positives, and the most common reasons behind them

:: Most malware is sent through email; using shorteners in emails is phishy behavior. False positives are not very common. The most common reasons are that in emails, readers don't understand what is malicious or they don’t like what they see; so, they report it.

* Why RBL providers do not share information with each other

:: They use different methodologies, look for different types of abuse, and do not want to publish their findings when there are not mitigation mechanisms

* Why evidence is not included in RBLs

:: Including evidence is not possible at scale (2-3K emails/second) because it would reveal [[Honeypots]]

''Critiques and concerns included:''

:: Reg Levy: false positives;

:: Joanna Kulesza: end users ending up on RBLs and transparency on criteria.

:: [[John McCormac]]: Detection versus reporting may be a limiting factor for RBLs, which in turn may always be behind the curve. "One possible metric that could help some RBLs would be whether a domain name was registered at full fee or at a heavy discount. It might be a bit of a meta-metric. In terms of webspam doms, the patterns in new gTLDs from web usage surveys revealed that 95% of them were gone within a year, locking registries into a kind of discount addiction to survive."

:: [[Crystal Ondo]]: the difference between maliciously registered vs hacked domains needs to be underscored. "A lot of domains that end up on RBLs are victims themselves, not bad actors. Further muddying the waters."

:: Roman Hussey: RBLs, such as [[Abuse CH]], do not have a way to determine whether a domain name is a victim of a compromise or registered for malicious purposes for two reasons: Missing [[Whois]] (not registrant data, but the sponsoring registrar and registration data) and missing pDNS data (when the domain name was first observed).

===Policy===

====GNSO====

@@ Line 36: / Line 36: @@
 ====Reputation Block Lists====
 This plenary was guided by the objective of helping the ICANN community understand [[RBL]]s: what they are, how they're made, what they can be used for, obstacles, and advances. Three people ([[Carel Bitter]], [[Roman Huessy]], and [[Ben Coon]]) from the RBL field were interviewed by the moderator ([[LG Forsberg]]. A cybersecurity expert from ICANN's [[OCTO]] ([[Samaneh Tajalizadehkhoob]]), the vice-chair of [[M3AAWG]] ([[Matt Thomas]]), the co-chair of ICANN's DNS Abuse working group ([[Reg Levy]]), and the co-vice chair of [[ALAC]] Joanna Kulesza also spoke.
-The panel discussed:
+''The panel discussed:''
-* whether the lists are maintained through automation or by humans
+* Whether the lists are maintained through automation or by humans
-* the frequency of false positives, and the most common reasons behind them
+:: The datasets are generally automated but humans spot-check URLs that don’t score high enough to be included in the RBL, add/remove them from the lists, and to verify false positives.
+* The frequency of false positives, and the most common reasons behind them
+:: Most malware is sent through email; using shorteners in emails is phishy behavior. False positives are not very common. The most common reasons are that in emails, readers don't understand what is malicious or they don’t like what they see; so, they report it.
 * Why RBL providers do not share information with each other
+:: They use different methodologies, look for different types of abuse, and do not want to publish their findings when there are not mitigation mechanisms
 * Why evidence is not included in RBLs
+:: Including evidence is not possible at scale (2-3K emails/second) because it would reveal [[Honeypots]]
+''Critiques and concerns included:''
+:: Reg Levy: false positives;
+:: Joanna Kulesza: end users ending up on RBLs and transparency on criteria.
+:: [[John McCormac]]: Detection versus reporting may be a limiting factor for RBLs, which in turn may always be behind the curve. "One possible metric that could help some RBLs would be whether a domain name was registered at full fee or at a heavy discount. It might be a bit of a meta-metric. In terms of webspam doms, the patterns in new gTLDs from web usage surveys revealed that 95% of them were gone within a year, locking registries into a kind of discount addiction to survive."
+:: [[Crystal Ondo]]: the difference between maliciously registered vs hacked domains needs to be underscored. "A lot of domains that end up on RBLs are victims themselves, not bad actors. Further muddying the waters."
+:: Roman Hussey: RBLs, such as [[Abuse CH]], do not have a way to determine whether a domain name is a victim of a compromise or registered for malicious purposes for two reasons: Missing [[Whois]] (not registrant data, but the sponsoring registrar and registration data) and missing pDNS data (when the domain name was first observed).
 ===Policy===
 ====GNSO====