RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
At 06:02 AM 11/25/2003 -0800, Hallam-Baker, Phillip wrote: Especially for domains, it's important to do some validation, though in the absence of widely-deployed DNSSEC, it's hard to do automatically. DNSSEC is not happening, [...] We do not need DNSSEC, we just need a notice in the DNS. It would be a relatively easy task to walk the .com zone and dump out a list of all the zones which contain a 'do not spam' TXT property record. I suppose you could do that, though it's probably harder to coordinate that for subdomains, whose owners are less likely to be directly managing their DNS records. There's a scalability problem that has to be solved, which is how to prevent a DOS-by-signing-up-too-many-addresses attack. I do not expect that to be a problem, that would be a problem for the contractor. Limit the number of direct registrations from a particular IP address within a given time interval. You'd probably want to do special cases for large domains like AOL, etc., where the users have limited gateways to the internet. You're still vulnerable to DDOS-type attacks by armies of zombies, though of course they've got lots of other bad things they can do. It is likely to result in the cost of the system being considerably more than the cost of a couple of mid range servers and some software. This is not a new phenomena. Too true. It's too bad, because you'd only need a couple hundred million records for the US, and signing up is the only part that's got real-time performance constraints.
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Hallam-Baker, Phillip [EMAIL PROTECTED] writes: DNSSEC is not happening, blame Randy Bush and the IESG for refusing the working group consensus and imposing their own idea that cannot be deployed. An experimental protocol that increases the volume of data in the .com zone by an order of magnitude (read Gbs of data) is simply unacceptable. Do you have any more details on this for those who don't normally follow DNSSEC? Peter.
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Do you have any more details on this for those who don't normally follow DNSSEC? It is a sad story. Politics and the magic circle. If people are wondering why the major industry players have abandoned the IETF read on. This is only one example of the type, other companies have similar issues. When VeriSign bought Network Solutions one of the main opportunities we saw was to deploy DNSSEC. There is a limit to what you can achieve in the context of DNS, anyone can get a domain name without providing authentication so proving that someone is the legitimate holder of example.com does not mean you want to give them your credit card number. On the other hand it would be quite feasible to deploy a class 1 level assurance system with low cost and ubiquitous coverage. The problem with the DNSSEC specification is the NXT record that links from one signed zone to the next. In the original specification you have to create a link record for every single domain in the zone. This causes the amount of data in the zone to increase enormously. This is fine if you have a typical zone with a few hundred or thousand entries. It is a completely different matter if you are running the dotCOM zone and you have several Gb of zone data already, a contract that specifies a very highl level of reliability and a constant series of DDoS and other attacks going on (about 1000 penetration attempts per day). There is no way that the people with responsibility for running the dotCOM zone are going to deploy a system that has such an immediate effect on operations. The amount of data expands by an order of magnitude. So we proposed a fix. The original security review was performed by myself and Warwick Ford. Instead of linking between every record you only link from one secured zone to the next. This was called 'optin'. This has exactly the same security as the original proposal but the impact on deployment is much less. The cost of deployment scales with the number of people using DNSSEC. The only change in the security is that with OPTIN there is a diferent way that an attacker can perform an insertion attack, that is causing someone to believe a zone is registered when it is not. The attack is not very plausible and at the end of the day the only impact is that we are out the six bucks for the registration. Anyone can insert domains into dotCOM, just see a registrar. The objection to the idea was that this is a VeriSign problem and the WG had zero responsibility for creating a specification that was deployable by the operators of large zones which should not exist anyway. There was also a claim that there was a personality issue, that if proponents of OPTIN had adopted the correct position as a supplicant that their petition might have been considered more favorably. The evidence is against this, every time the go with the flow strategy was attempted the DNS people would call me up six months later and say 'we have been screwed again'. This was understood by virtually everyone in the DNSSEC working group. The chair disagreed. It was at this point that I discovered that the IETF is not open and not inclusive. Every time the working group agreed on OPTIN the specification would be taken on a detour. The first time for consultation in a closed committee called the DNS Directorate. To cut a long story short the plan was filibustered for three years and then after finally comming to last call. After passing last call without objection the chair scheduled two further last calls before we finally came to a result where a clear majority of the group were in favor, four fifths were either in favor or willing to allow it to go forward and two individuals were opposed. So the chair used his perogative to impose his 'consensus' on the group. The result is that OPTIN is on the experimental track, not a proposed standard as the clear consensus of the group was that it should be. This in turn means that it is far more difficult to persuade ICANN to allow deployment of the specification with its experimental status. The IETF was designed the way it is to allow a small clique to hold power while pretending to be open and inclusive. All that Nomcon gumpf is really designed to make it impossible for the nominating committee to make more than a few changes to the IESG each time arround. The result of this type of behaviour is that the IETF has practically no influence in the industry. DNSSEC and IPv6 have been 'about to deploy' for over a decade now. There is still no clue as to how IPSEC works in any application beyond VPN, which is not what it is designed for. SSL makes a better remote access VPN protocol than IPSEC, works through NAT boxes without kludges for a start. The other industry players have similar stories. The industry is taking notice of the ideas comming out of this WG. But they are not very likely to accept a standards process unless it is based on bi-weekly teleconference calls and all major decisions are subject to
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Hallam-Baker, Phillip [EMAIL PROTECTED] writes: DNSSEC is not happening, blame Randy Bush and the IESG for refusing the working group consensus and imposing their own idea that cannot be deployed. An experimental protocol that increases the volume of data in the .com zone by an order of magnitude (read Gbs of data) is simply unacceptable. Do you have any more details on this for those who don't normally follow DNSSEC? Peter.
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Do you have any more details on this for those who don't normally follow DNSSEC? It is a sad story. Politics and the magic circle. If people are wondering why the major industry players have abandoned the IETF read on. This is only one example of the type, other companies have similar issues. When VeriSign bought Network Solutions one of the main opportunities we saw was to deploy DNSSEC. There is a limit to what you can achieve in the context of DNS, anyone can get a domain name without providing authentication so proving that someone is the legitimate holder of example.com does not mean you want to give them your credit card number. On the other hand it would be quite feasible to deploy a class 1 level assurance system with low cost and ubiquitous coverage. The problem with the DNSSEC specification is the NXT record that links from one signed zone to the next. In the original specification you have to create a link record for every single domain in the zone. This causes the amount of data in the zone to increase enormously. This is fine if you have a typical zone with a few hundred or thousand entries. It is a completely different matter if you are running the dotCOM zone and you have several Gb of zone data already, a contract that specifies a very highl level of reliability and a constant series of DDoS and other attacks going on (about 1000 penetration attempts per day). There is no way that the people with responsibility for running the dotCOM zone are going to deploy a system that has such an immediate effect on operations. The amount of data expands by an order of magnitude. So we proposed a fix. The original security review was performed by myself and Warwick Ford. Instead of linking between every record you only link from one secured zone to the next. This was called 'optin'. This has exactly the same security as the original proposal but the impact on deployment is much less. The cost of deployment scales with the number of people using DNSSEC. The only change in the security is that with OPTIN there is a diferent way that an attacker can perform an insertion attack, that is causing someone to believe a zone is registered when it is not. The attack is not very plausible and at the end of the day the only impact is that we are out the six bucks for the registration. Anyone can insert domains into dotCOM, just see a registrar. The objection to the idea was that this is a VeriSign problem and the WG had zero responsibility for creating a specification that was deployable by the operators of large zones which should not exist anyway. There was also a claim that there was a personality issue, that if proponents of OPTIN had adopted the correct position as a supplicant that their petition might have been considered more favorably. The evidence is against this, every time the go with the flow strategy was attempted the DNS people would call me up six months later and say 'we have been screwed again'. This was understood by virtually everyone in the DNSSEC working group. The chair disagreed. It was at this point that I discovered that the IETF is not open and not inclusive. Every time the working group agreed on OPTIN the specification would be taken on a detour. The first time for consultation in a closed committee called the DNS Directorate. To cut a long story short the plan was filibustered for three years and then after finally comming to last call. After passing last call without objection the chair scheduled two further last calls before we finally came to a result where a clear majority of the group were in favor, four fifths were either in favor or willing to allow it to go forward and two individuals were opposed. So the chair used his perogative to impose his 'consensus' on the group. The result is that OPTIN is on the experimental track, not a proposed standard as the clear consensus of the group was that it should be. This in turn means that it is far more difficult to persuade ICANN to allow deployment of the specification with its experimental status. The IETF was designed the way it is to allow a small clique to hold power while pretending to be open and inclusive. All that Nomcon gumpf is really designed to make it impossible for the nominating committee to make more than a few changes to the IESG each time arround. The result of this type of behaviour is that the IETF has practically no influence in the industry. DNSSEC and IPv6 have been 'about to deploy' for over a decade now. There is still no clue as to how IPSEC works in any application beyond VPN, which is not what it is designed for. SSL makes a better remote access VPN protocol than IPSEC, works through NAT boxes without kludges for a start. The other industry players have similar stories. The industry is taking notice of the ideas comming out of this WG. But they are not very likely to accept a standards process unless it is based on bi-weekly teleconference calls and all major decisions are subject to
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Especially for domains, it's important to do some validation, though in the absence of widely-deployed DNSSEC, it's hard to do automatically. DNSSEC is not happening, blame Randy Bush and the IESG for refusing the working group consensus and imposing their own idea that cannot be deployed. An experimental protocol that increases the volume of data in the .com zone by an order of magnitude (read Gbs of data) is simply unacceptable. We do not need DNSSEC, we just need a notice in the DNS. It would be a relatively easy task to walk the .com zone and dump out a list of all the zones which contain a 'do not spam' TXT property record. This has the secondary advantage that it is not necessary to actualy consult the list, the authoritative information is in DNS. There's a scalability problem that has to be solved, which is how to prevent a DOS-by-signing-up-too-many-addresses attack. I do not expect that to be a problem, that would be a problem for the contractor. Limit the number of direct registrations from a particular IP address within a given time interval. It is likely to result in the cost of the system being considerably more than the cost of a couple of mid range servers and some software. This is not a new phenomena. Phill
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
At 04:20 PM 11/21/2003 -0800, Hallam-Baker, Phillip wrote: We need to consider the technical workings of the do-not-spam list and the requirements that we would like the FTC to meet. .. [reasonable goals] ... [hashed-form lists instead of plaintext]... 5) Allow domain name owners to list their domains. 6) Provide for authentication of listing requests Especially for domains, it's important to do some validation, though in the absence of widely-deployed DNSSEC, it's hard to do automatically. Perhaps 3-way-handshake email to [EMAIL PROTECTED] or the whois administrative contact address. (This also has the side-effect of requiring people to actually use their postmaster addresses, at least for fifteen minutes or so :-) And while hashing has the obvious risk of dictionary attacks, it'll at least cut back on some of the abuses, especially if the list is dynamic and the spamware vendors who do the dictionary attacks want to charge lots of money for it. Also, the scale's a lot more annoying searching a million obvious names on each of 20 million domains with a hash that takes a second per hit, though Moore's Law will obviously erode the hash time. Obviously spammers will target popular mail systems first. However, there are two special email address forms that complicate this a bit - tagged addresses - [EMAIL PROTECTED] There are several different syntaxes for this - plusses, dashes, etc., and either you just ignore the problem (let the user register however many tagged addresses they want), or else you special-case the rules so that bulk-emailers who want to send mail to a plus-tagged address also must check the untagged version. - per-user subdomains - [EMAIL PROTECTED] Technically this is no different than any other per-domain blocking, but administratively it's different, because there's no whois record and there might not be a postmaster address. There's a scalability problem that has to be solved, which is how to prevent a DOS-by-signing-up-too-many-addresses attack. An example would be a Turing test image on a web page (which has the downside of preventing automated signups, as well as annoying blind people), or else requiring a hashcash puzzle that takes ten times as long as the list's hash function.
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Especially for domains, it's important to do some validation, though in the absence of widely-deployed DNSSEC, it's hard to do automatically. DNSSEC is not happening, blame Randy Bush and the IESG for refusing the working group consensus and imposing their own idea that cannot be deployed. An experimental protocol that increases the volume of data in the .com zone by an order of magnitude (read Gbs of data) is simply unacceptable. We do not need DNSSEC, we just need a notice in the DNS. It would be a relatively easy task to walk the .com zone and dump out a list of all the zones which contain a 'do not spam' TXT property record. This has the secondary advantage that it is not necessary to actualy consult the list, the authoritative information is in DNS. There's a scalability problem that has to be solved, which is how to prevent a DOS-by-signing-up-too-many-addresses attack. I do not expect that to be a problem, that would be a problem for the contractor. Limit the number of direct registrations from a particular IP address within a given time interval. It is likely to result in the cost of the system being considerably more than the cost of a couple of mid range servers and some software. This is not a new phenomena. Phill
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Yeah, Yeah dictionary attacks... The key is that the search space is actually thinly populated enough to make dictionary attack hard. Most usernames are 6 characters or more, many include numbers, that is about 26^6 worth of search space per domain. Of course this is not evenly populated, but the odd thing is that the usernames turn out to be more random than the average password. This is because random is not unguessable. Many usernames are surnames, many are compounds of initial plus surname, only a relative handfull are commonly used names and those tend to get grabbed fast. so you have a pretty big search space, millions of possibilities and that for each one of fifty million domains. The same does not hold for do-not-call lists. The problem there is that something like 80% of the numbers available at active exchanges are already allocated. Most of the stock of unused numbers are on exchanges that have not yet been allocated. Since something like 30% of subscribers sign up for do not call the result is that dictonary attacks are easy. Also we add out of service addresses that get spammed anyway to the list. So the list is not an accurate way to find out if an address is in service or not. Alan knows quite a few addresses that get spammed that are invalid. -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 7:21 PM To: 'Steve Schear' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp] We need to consider the technical workings of the do-not-spam list and the requirements that we would like the FTC to meet. I propose as a minimum: 1) Allow individual subscribers to list their email addresses with the service. 2) Permit mail sender to quickly determine whether a given email is on the list 3) Be distributable in a form that does not permit use as a mailing list. 4) Permit the storage of attributes in association with each listing, minimally the date of subscription. In addition we might add: 5) Allow domain name owners to list their domains. 6) Provide for authentication of listing requests These requirements can be met using completely generic and to my knowledge unencumbered technology. For the purposes of avoiding patent encumberabces I disclose the following - I published note on the basic idea of using a one way hash to conceal an email address on a do not spam list in 1995, I also implemented the scheme at that time. The idea is not entirely novel, hash databases have been used for at least twenty years, there may also be similar ideas in the cryptography litterature. My proposal would be to use a message authentication function such as HMAC-SHA1 with a key such as SHA1 (FTC Do Not Spam List) to create a unique digest function for the purpose. There is a security consideration here, use of a digest such as SHA1(email) might lead to chosen protocol attacks. To add an individual email address [EMAIL PROTECTED] to the list we calculate HMAC ([EMAIL PROTECTED]) to create the key. A domain may be represented by the string example.com. To determine whether the address [EMAIL PROTECTED] is on the list it is necessary to test for both the specific email address and the domain. [This can be made to meet arbitrarily complex requirements] The list is distributed as a set of key/value pairs. Sorting the list according to the key values allows rapid lookups by means of binary search, or since the hash function is guaranteed homogenous using ranged search using the hash value as an estimator for the index position. It is not necessary to distribute the list sorted. There are also a few tricks that can be used to reduce the usefulness of such a list for address validation. This same concept can be used to conceal the filter terms used in cersorware. Phill ___ Asrg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/asrg
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
We need to consider the technical workings of the do-not-spam list and the requirements that we would like the FTC to meet. I propose as a minimum: 1) Allow individual subscribers to list their email addresses with the service. 2) Permit mail sender to quickly determine whether a given email is on the list 3) Be distributable in a form that does not permit use as a mailing list. 4) Permit the storage of attributes in association with each listing, minimally the date of subscription. In addition we might add: 5) Allow domain name owners to list their domains. 6) Provide for authentication of listing requests These requirements can be met using completely generic and to my knowledge unencumbered technology. For the purposes of avoiding patent encumberabces I disclose the following - I published note on the basic idea of using a one way hash to conceal an email address on a do not spam list in 1995, I also implemented the scheme at that time. The idea is not entirely novel, hash databases have been used for at least twenty years, there may also be similar ideas in the cryptography litterature. My proposal would be to use a message authentication function such as HMAC-SHA1 with a key such as SHA1 (FTC Do Not Spam List) to create a unique digest function for the purpose. There is a security consideration here, use of a digest such as SHA1(email) might lead to chosen protocol attacks. To add an individual email address [EMAIL PROTECTED] to the list we calculate HMAC ([EMAIL PROTECTED]) to create the key. A domain may be represented by the string example.com. To determine whether the address [EMAIL PROTECTED] is on the list it is necessary to test for both the specific email address and the domain. [This can be made to meet arbitrarily complex requirements] The list is distributed as a set of key/value pairs. Sorting the list according to the key values allows rapid lookups by means of binary search, or since the hash function is guaranteed homogenous using ranged search using the hash value as an estimator for the index position. It is not necessary to distribute the list sorted. There are also a few tricks that can be used to reduce the usefulness of such a list for address validation. This same concept can be used to conceal the filter terms used in cersorware. Phill
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
We need to consider the technical workings of the do-not-spam list and the requirements that we would like the FTC to meet. I propose as a minimum: 1) Allow individual subscribers to list their email addresses with the service. 2) Permit mail sender to quickly determine whether a given email is on the list 3) Be distributable in a form that does not permit use as a mailing list. 4) Permit the storage of attributes in association with each listing, minimally the date of subscription. In addition we might add: 5) Allow domain name owners to list their domains. 6) Provide for authentication of listing requests These requirements can be met using completely generic and to my knowledge unencumbered technology. For the purposes of avoiding patent encumberabces I disclose the following - I published note on the basic idea of using a one way hash to conceal an email address on a do not spam list in 1995, I also implemented the scheme at that time. The idea is not entirely novel, hash databases have been used for at least twenty years, there may also be similar ideas in the cryptography litterature. My proposal would be to use a message authentication function such as HMAC-SHA1 with a key such as SHA1 (FTC Do Not Spam List) to create a unique digest function for the purpose. There is a security consideration here, use of a digest such as SHA1(email) might lead to chosen protocol attacks. To add an individual email address [EMAIL PROTECTED] to the list we calculate HMAC ([EMAIL PROTECTED]) to create the key. A domain may be represented by the string example.com. To determine whether the address [EMAIL PROTECTED] is on the list it is necessary to test for both the specific email address and the domain. [This can be made to meet arbitrarily complex requirements] The list is distributed as a set of key/value pairs. Sorting the list according to the key values allows rapid lookups by means of binary search, or since the hash function is guaranteed homogenous using ranged search using the hash value as an estimator for the index position. It is not necessary to distribute the list sorted. There are also a few tricks that can be used to reduce the usefulness of such a list for address validation. This same concept can be used to conceal the filter terms used in cersorware. Phill
RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
Yeah, Yeah dictionary attacks... The key is that the search space is actually thinly populated enough to make dictionary attack hard. Most usernames are 6 characters or more, many include numbers, that is about 26^6 worth of search space per domain. Of course this is not evenly populated, but the odd thing is that the usernames turn out to be more random than the average password. This is because random is not unguessable. Many usernames are surnames, many are compounds of initial plus surname, only a relative handfull are commonly used names and those tend to get grabbed fast. so you have a pretty big search space, millions of possibilities and that for each one of fifty million domains. The same does not hold for do-not-call lists. The problem there is that something like 80% of the numbers available at active exchanges are already allocated. Most of the stock of unused numbers are on exchanges that have not yet been allocated. Since something like 30% of subscribers sign up for do not call the result is that dictonary attacks are easy. Also we add out of service addresses that get spammed anyway to the list. So the list is not an accurate way to find out if an address is in service or not. Alan knows quite a few addresses that get spammed that are invalid. -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 7:21 PM To: 'Steve Schear' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp] We need to consider the technical workings of the do-not-spam list and the requirements that we would like the FTC to meet. I propose as a minimum: 1) Allow individual subscribers to list their email addresses with the service. 2) Permit mail sender to quickly determine whether a given email is on the list 3) Be distributable in a form that does not permit use as a mailing list. 4) Permit the storage of attributes in association with each listing, minimally the date of subscription. In addition we might add: 5) Allow domain name owners to list their domains. 6) Provide for authentication of listing requests These requirements can be met using completely generic and to my knowledge unencumbered technology. For the purposes of avoiding patent encumberabces I disclose the following - I published note on the basic idea of using a one way hash to conceal an email address on a do not spam list in 1995, I also implemented the scheme at that time. The idea is not entirely novel, hash databases have been used for at least twenty years, there may also be similar ideas in the cryptography litterature. My proposal would be to use a message authentication function such as HMAC-SHA1 with a key such as SHA1 (FTC Do Not Spam List) to create a unique digest function for the purpose. There is a security consideration here, use of a digest such as SHA1(email) might lead to chosen protocol attacks. To add an individual email address [EMAIL PROTECTED] to the list we calculate HMAC ([EMAIL PROTECTED]) to create the key. A domain may be represented by the string example.com. To determine whether the address [EMAIL PROTECTED] is on the list it is necessary to test for both the specific email address and the domain. [This can be made to meet arbitrarily complex requirements] The list is distributed as a set of key/value pairs. Sorting the list according to the key values allows rapid lookups by means of binary search, or since the hash function is guaranteed homogenous using ranged search using the hash value as an estimator for the index position. It is not necessary to distribute the list sorted. There are also a few tricks that can be used to reduce the usefulness of such a list for address validation. This same concept can be used to conceal the filter terms used in cersorware. Phill ___ Asrg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/asrg
