ICANN 71: Difference between revisions

Line 35:

*[[Alexander Seger]] representing the European Council, gave an update on the 2nd Additional Protocol to the Budapest Convention on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime (the [[Budapest Convention]]), which has 66 member parties and concerns criminal law, not civil

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

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:''

* Whether the lists are maintained through automation or by humans

:: 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 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 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 [[Phishing|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.

Line 50:

:: [[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).

:: 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 p[[DNS]] data (when the domain name was first observed).

===Policy===

@@ Line 35: / Line 35: @@
 *[[Alexander Seger]] representing the European Council, gave an update on the 2nd Additional Protocol to the Budapest Convention on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime (the [[Budapest Convention]]), which has 66 member parties and concerns criminal law, not civil
 ====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.
+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:''
 * Whether the lists are maintained through automation or by humans
-:: 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 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 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 [[Phishing|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.
@@ Line 50: / Line 50: @@
 :: [[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).
+:: 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 p[[DNS]] data (when the domain name was first observed).
 ===Policy===