ICANN Blog : Relying on ICANN Community-Developed Processes for a Safe, Secure Interne
ICANN Blog : Relying on ICANN Community-Developed Processes for a Safe, Secure Internet 5 January 2022 John Jeffrey <https://www.icann.org/#>, General Counsel and Secretary, Co-Deputy to the President and CEOTheresa Swinehart <https://www.icann.org/#>, SVP, Global Domains and Strategy, Co-Deputy to the President and CEO We have observed community discussions and received comments and questions about ICANN's top-level domain (TLD) Registry Agreement assignment approval process and a recent Urgent Reconsideration Request considered by the ICANN Board Accountability Mechanisms Committee (BAMC). We believe it is important to provide context to some of these discussions. https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-...
On 1/6/22 9:39 AM, Dev Anand Teelucksingh via At-Large wrote:
ICANN Blog : Relying on ICANN Community-Developed Processes for a Safe, Secure Internet
In our race to be safe and secure we are forgetting about maintenance, monitoring, diagnostics, and repair. Our layers of security are making it harder to keep the net running. I've been working on the monitor/diagnose/repair side of things for more than 4 decades. I've watched as the number and strength of security walls being erected, walls that make running the net hard, is increasing. Yes, we need security. But we also need means to keep the net running and to fix it when thing go awry. Few have been willing to discuss this trade-off between security and maintenance/repair. The solution may require empowerment of people with special privileges and use of privileged tools of exceptional power; a cadre of privileged internet priests. The creation of such a cadre has been strongly resisted when that cadre has taken the form of things like backdoors into cryptography. However, to keep the net alive sometimes people and tools are going to have to go into the cellars and sewers of the net where unpleasant and uncomfortable things will be seen. To my mind this all comes down to ethics and trust, the trust that those who have special powers to maintain the net operate within a set of ethical guidelines backed by strong enforcement. At the present time the internet is like a patent on a surgical table. Perhaps the patient is sick, perhaps not, perhaps in need of immediate care. But on our present internet the doctors are locked outside the building and the the surgeon is allowed only butter knives rather than sharp scalpels. The internet has become a lifeline utility - health, safety, and even lives depend on it. That will increase in the future. Yet we have only weak and filtered means to monitor the net, to understand its pathologies; to even know when things are working badly (whether due to failure, attack, or simple mis-configuration) are, at best, weak; and to make repairs. Questions of security must be considered, hand-in-hand, with matters of the necessary access and the sharp, potentially dangerous, tools that must be wielded to keep thins operating well. --karl--
It has occurred to me that perhaps one of Putin's major goals (assuming he is pulling these strings) is to get the rest of the world to spend itself to death on network security much like the (possibly apocryphal) claim that we (US) caused the USSR's demise by causing them to spend themselves to death on defense. It doesn't matter if that's factually true, it probably isn't. The USSR's spending on defense didn't rise much in the claimed era. Only whether Putin believes it to be true, or is an opportunity. It is a game which is weighted in favor of the attacker who only has to get it right once in a while to do a lot of damage while the defender has to try to thwart every effort. That said I'll say what I've been saying for decades: We never designed the net to be secure. We never designed it to do things which require so much security. That was an afterthought largely beginning in the mid-90s when some realized that they could make (and/or save) a lot of money if they could proceed on the fiction that the net was or could be made secure. So we (the technological community) bought into that fiction and proceeded to try to layer on security. It hasn't really worked. It may not even be possible. Or, perhaps put better, we only encouraged those exploiting the net for their own pecuniary interests to keep coming back for more security acting as if we'd promised it was secure but haven't tried hard enough and have let them down. We didn't ever promise that. Show me where, in writing, anyone ever promised anyone that. The net was designed to share pictures of cats, bottomless talking clubs, and document sharing, all of little importance, as frictionlessly, cheaply, quickly, and without accountability as possible. If those making literally trillions off the net actually care about security perhaps they could throw in some billions to achieve it and stop hoping they can humiliate this vast army of largely unpaid volunteers to deliver it to them for free. On January 6, 2022 at 14:39 at-large@atlarge-lists.icann.org (Karl Auerbach via At-Large) wrote:
On 1/6/22 9:39 AM, Dev Anand Teelucksingh via At-Large wrote:
ICANN Blog : Relying on ICANN Community-Developed Processes for a Safe, Secure Internet
In our race to be safe and secure we are forgetting about maintenance, monitoring, diagnostics, and repair.
Our layers of security are making it harder to keep the net running.
I've been working on the monitor/diagnose/repair side of things for more than 4 decades. I've watched as the number and strength of security walls being erected, walls that make running the net hard, is increasing.
Yes, we need security. But we also need means to keep the net running and to fix it when thing go awry.
Few have been willing to discuss this trade-off between security and maintenance/repair.
The solution may require empowerment of people with special privileges and use of privileged tools of exceptional power; a cadre of privileged internet priests.
The creation of such a cadre has been strongly resisted when that cadre has taken the form of things like backdoors into cryptography. However, to keep the net alive sometimes people and tools are going to have to go into the cellars and sewers of the net where unpleasant and uncomfortable things will be seen. To my mind this all comes down to ethics and trust, the trust that those who have special powers to maintain the net operate within a set of ethical guidelines backed by strong enforcement.
At the present time the internet is like a patent on a surgical table. Perhaps the patient is sick, perhaps not, perhaps in need of immediate care. But on our present internet the doctors are locked outside the building and the the surgeon is allowed only butter knives rather than sharp scalpels.
The internet has become a lifeline utility - health, safety, and even lives depend on it. That will increase in the future.
Yet we have only weak and filtered means to monitor the net, to understand its pathologies; to even know when things are working badly (whether due to failure, attack, or simple mis-configuration) are, at best, weak; and to make repairs.
Questions of security must be considered, hand-in-hand, with matters of the necessary access and the sharp, potentially dangerous, tools that must be wielded to keep thins operating well.
--karl--
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 1/6/22 5:05 PM, bzs@theworld.com wrote:
We never designed it to do things which require so much security. ...
The net was designed to share pictures of cats...
Our mileage is varying. There are diverse histories of the net - the history of the net does kinda resemble that fabled elephant and the blind men. I worked for the US Joint Chiefs of Staff back in the early 1970's and then for various three-letter US agencies in Maryland for much of the rest of that decade. We started with ARPAnet technology and moved forward. Our focus was operating system and network security (for which I designed and built the first verified B-level secure operating system.) Anyway... it was always our goal back then to bake security deeply into the net. And by the latter part of the 1970's we had invented a lot of stuff that had to be re-invented later, such as IPsec, key management, virtual networks, and lots and lots of software/hardware that used security tagging and capabilities. We actually implemented most of these things and got them working in production environments. (Why re-invented? Because we were doing stuff for agencies that were extremely paranoid about national security implications - remember during the 1970's the cold war was running very hot. So we could not publish anything about what we worked on.) --karl--
On January 6, 2022 at 18:12 karl@cavebear.com (Karl Auerbach) wrote:
On 1/6/22 5:05 PM, bzs@theworld.com wrote:
We never designed it to do things which require so much security. ...
The net was designed to share pictures of cats...
Our mileage is varying. There are diverse histories of the net - the history of the net does kinda resemble that fabled elephant and the blind men.
I worked for the US Joint Chiefs of Staff back in the early 1970's and then for various three-letter US agencies in Maryland for much of the rest of that decade. We started with ARPAnet technology and moved forward. Our focus was operating system and network security (for which I designed and built the first verified B-level secure operating system.)
The Orange Book (which defined A/B/C security) was mostly about compartmentalization, how to keep people with different levels of clearance, or just no "need to know", away from each other on shared mainframes. With an eye towards the possibility that some of those people on the inside might be hostile actors. It was obsolesced by computers becoming cheap enough that you just didn't share resources between disjoint departments, and other factors. No doubt when networks were introduced they developed similar concerns on shared networks within secure facilities but these weren't shared with public networks in general (I'm sure there were exceptions, these are huge organizations.) So it wasn't about how to securely take credit card and other information from otherwise unvetted parties across uncontrolled public networks. It was about keeping information marked confidential out of the hands of the people down the hall if they had no clearance.
Anyway... it was always our goal back then to bake security deeply into the net. And by the latter part of the 1970's we had invented a lot of stuff that had to be re-invented later, such as IPsec, key management, virtual networks, and lots and lots of software/hardware that used security tagging and capabilities. We actually implemented most of these things and got them working in production environments.
(Why re-invented? Because we were doing stuff for agencies that were extremely paranoid about national security implications - remember during the 1970's the cold war was running very hot. So we could not publish anything about what we worked on.)
I think the disconnect here is "public networks" and commerce etc on those public networks. Yes computer and network security has long been an active topic, some of it going back before the first ARPAnet projects (e.g., Multics, rings of security, ca 1969.) But securing commerce and connection to an open, public network was a new idea beyond logins, passwords and similar. When was the first RFC regarding anything much beyond logins and passwords? I could go look. Anyhow, Apples vs Orange Books. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 1/6/22 21:54, bzs@theworld.com wrote:
The Orange Book (which defined A/B/C security) was mostly about compartmentalization, how to keep people with different levels of clearance, or just no "need to know", away from each other on shared mainframes. With an eye towards the possibility that some of those people on the inside might be hostile actors.
My department wrote the original drafts of the Orange Book. It is amazingly hard to specify, with the mathematical precision we needed for formal software verification, that one security domain may not send information to a lower classification domain. That was called the *-property ("star property"). We wrote some other documents regarding expansion of the Orange Book ideas into the realm of networks. Those papers were physical paper and have sunk into the infinite maw of the US gov't - not quite classified but rather in some forgotten banker's box or file cabinet at some forgotten location. One paper I really wished I could find is one where I worked on methods of debugging a tightly secured operating system. We were working with capability architectures at the time so we even had the hardware working against debugging. You and I have both had a long time interest in network tools (and dies), so I suspect we share the satisfaction of being in the right place at the right time with the right tools.
It was obsolesced by computers becoming cheap enough that you just didn't share resources between disjoint departments, and other factors.
One could only wish that that tendency would have persisted. These days we tend to live in a world where data is held in big shared storage. Those big storage places have, of late, often exposed their goods either due to weakness in their software, weakness in internet access protocols, or rather frequently procedural failures ranging from people responding to phishing attacks to things like DNS resolvers that give back misleading answers. A lot of security is knowing when to open the door of access and knowing when to slam it shut and push the alarm button. That often requires firm credentials of the "subject" trying to make the access. We've been reluctant on the internet to create what amounts to a lord-of-identity. That goes against the libertarian bent of many people. But even when identity is asserted we often do a weak job of authenticating it. For example TLS connections often validate the full credential chain of one of the ends of the connection, not both. What we found, and this was even more important on networks, than inside a single machine, was that the chain of access was important. If A wanted resource X it often was important that A make a request of B which in turn could access X. Capability systems were a great tool for this, but those don't work well across networks. And then we come to my main point - how do we fix things when security walls are present and working? How does Joe Repairman prove that he can come in and hook up to the crown jewels of the data flowing in a network or stored somewhere? How does Joe Repairman do that over a network? I spent much of the 1980's keeping the networks of a very large bank alive. When I stated we had a mere $20Billion flowing through our nets every night. That's a pittance by today's standards. I often had to get deep access (sometimes in a physical sense - some of our gear was buried deep under the streets of San Francisco.) We had locks and barriers out the wazoo. And encryption and procedures. But we had means by which I could get in, turn off encryption, fix things, and get out. Things have gotten far more reliable in the intervening years, which is good because today that kind of job would be nearly impossible to do, at least not as quickly, due to the layers of security that have grown. I've run into problems dealing with distributed attacks. When I tried to chain back through the various carriers, especially as I dealt with carriers across an ocean from me, I often found myself unable to obtain needed data because those providers didn't know me from Adam or just didn't want to help. Most of us have done that school experiment where we boil up a batch of sterile agar, put it into a sterile petri dish, cough on it, cap it, and then watch it for a few weeks. It begins with massive growth and then it starts to poison itself. The internet is like that petri dish - its grown like crazy but it is starting to pollute itself, either with hostile attacks, failing gear, or just bad software. The internet so far has had enough excess resources that we could sort of push those problems off to the side. But that era of averting our eyes is ending; we are going to have to become much more serious about finding problems and fixing them with dispatch. --karl--
I read all that and agree but for many this brief thread between us was probably TL;DR. Executive Summary: "Security" is one of those words like "freedom" or "justice" which we throw many ideas under. At best it's a complicated topic with many sub-topics. At worst it's a cacophony of aspirations which are very difficult to turn into coordinated efforts. Improving security often entails difficult trade-offs between freedom, control, privacy, overhead, and accountability. Everyone wants the results, few want to pay the cost. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Thanks, Barry, excellent statement. BUT: as you know, politics like buzzwords covering everything they like to do. Awareness Building is difficult. A major work for multistakeholder communities – like us. Best, Erich Gesendet von Mail für Windows Von: Barry Shein via At-Large Gesendet: Samstag, 8. Jänner 2022 00:36 An: karl@cavebear.com Cc: At-Large Worldwide Betreff: Re: [At-Large] ICANN Blog : Relying on ICANN Community-DevelopedProcesses for a Safe, Secure Interne I read all that and agree but for many this brief thread between us was probably TL;DR. Executive Summary: "Security" is one of those words like "freedom" or "justice" which we throw many ideas under. At best it's a complicated topic with many sub-topics. At worst it's a cacophony of aspirations which are very difficult to turn into coordinated efforts. Improving security often entails difficult trade-offs between freedom, control, privacy, overhead, and accountability. Everyone wants the results, few want to pay the cost. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
Thanks for this, Dev. WYn PH On 7 Jan 2022 1:39 am, Dev Anand Teelucksingh via At-Large wrote:
ICANN Blog : Relying on ICANN Community-Developed Processes for a Safe, Secure Internet
5 January 2022
John Jeffrey <https://www.icann.org/#>, General Counsel and Secretary, Co-Deputy to the President and CEOTheresa Swinehart <https://www.icann.org/#>, SVP, Global Domains and Strategy, Co-Deputy to the President and CEO
We have observed community discussions and received comments and questions about ICANN's top-level domain (TLD) Registry Agreement assignment approval process and a recent Urgent Reconsideration Request considered by the ICANN Board Accountability Mechanisms Committee (BAMC). We believe it is important to provide context to some of these discussions.
https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-...
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site:http://atlarge.icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (6)
-
bzs＠theworld.com -
Dev Anand Teelucksingh -
Evan Leibovitch -
Karl Auerbach -
Prof. Dr. Dr. Erich Schweighofer -
Winthrop Yu