NANOG Digest, Vol 53, Issue 105
Gregg
spaceradio123 at yahoo.com
Mon Jun 25 19:18:50 UTC 2012
It really is possible to have a secure society that does not require identification and authentication at every turn and for every move.
We the people will have to demand such freedom in order that it come to pass, however, because it is at odds with what money and power want. And where those go, sex follows. So, you could say, we have ourselves in a bit of a bind at the moment.
Gregg Squires
Consultant
Unimatics, Inc NV
Sent from my mobile fruit device.
On Jun 25, 2012, at 7:30 AM, nanog-request at nanog.org wrote:
> Send NANOG mailing list submissions to
> nanog at nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
> nanog-request at nanog.org
>
> You can reach the person managing the list at
> nanog-owner at nanog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>
>
> Today's Topics:
>
> 1. RE: LinkedIn password database compromised (Keith Medcalf)
> 2. RE: LinkedIn password database compromised (Keith Medcalf)
> 3. Re: LinkedIn password database compromised (Michael Thomas)
> 4. Re: How to fix authentication (was LinkedIn) (Kyle Creyts)
> 5. EULAs (James Smith)
> 6. Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> (Masataka Ohta)
> 7. Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> (Tim Franklin)
> 8. Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> (Tim Franklin)
> 9. Re: How to fix authentication (was LinkedIn) (AP NANOG)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 23 Jun 2012 18:52:10 -0600
> From: "Keith Medcalf" <kmedcalf at dessus.com>
> To: "Leo Bicknell" <bicknell at ufp.org>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: RE: LinkedIn password database compromised
> Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3 at mail.dessus.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Leo,
>
> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
>
> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
>
> If it does not use self-generated unsigned keys, it will never fly.
>
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>
>
>> -----Original Message-----
>> From: Leo Bicknell [mailto:bicknell at ufp.org]
>> Sent: Wednesday, 20 June, 2012 15:39
>> To: nanog at nanog.org
>> Subject: Re: LinkedIn password database compromised
>>
>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
>> wrote:
>>> Key management: doing it right is hard and probably beyond most end users.
>>
>> I could not be in more violent disagreement.
>>
>> First time a user goes to sign up on a web page, the browser should
>> detect it wants a key uploaded and do a simple wizard.
>>
>> - Would you like to create an online identity for logging into web
>> sites? Yes, No, Import
>>
>> User says yes, it creates a key, asking for an e-mail address to
>> identify it. Import to drag it in from some other program/format,
>> No and you can't sign up.
>>
>> Browser now says "would you like to sign up for website 'foobar.com'",
>> and if the user says "yes" it submits their public key including the
>> e-mail they are going to use to log on. User doesn't even fill out
>> a form at all.
>>
>> Web site still does the usual e-mail the user, click this link to verify
>> you want to sign up thing.
>>
>> User goes back to web site later, browser detects "auth needed" and
>> "public key foo" accepted, presents the cert, and the user is logged in.
>>
>> Notice that these steps _remove_ the user filling out forms to sign up
>> for simple web sites, and filling out forms to log in. Anyone who's
>> used cert-based auth at work is already familiar, the web site
>> "magically" knows you. This is MUCH more user friendly.
>>
>> So the big magic here is the user has to click on "yes" to create a key
>> and type in an e-mail once. That's it. There's no web of trust. No
>> identity verification (a-la ssl). I'm talking a very SSH like system,
>> but with more polish.
>>
>> Users would find it much more convenient and wonder why we ever used
>> passwords, I think...
>>
>> --
>> Leo Bicknell - bicknell at ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 23 Jun 2012 19:14:31 -0600
> From: "Keith Medcalf" <kmedcalf at dessus.com>
> To: "Rich Kulawiec" <rsk at gsp.org>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: RE: LinkedIn password database compromised
> Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5 at mail.dessus.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>> 2. Pre-compromised-at-the-factory smartphones and similar. There's
>> no reason why these can't be preloaded with spyware similar to CarrierIQ
>> and directed to upload all newly-created private keys to a central
>> collection point. This can be done, therefore it will be done, and when
>> some security researcher discovers it, the usual excuses and justifications
>> will be made by the designated spokesliars for the companies involved...
>> which will of course keep right on doing it, albeit perhaps with more
>> subterfuge.
>
>> Problem #2 is newer, but I'm willing to bet that it will also last
>> at least a decade and that it will get worse, since there are
>> substantial economic incentives to make it so.
>
> This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different.
>
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 23 Jun 2012 19:09:32 -0700
> From: Michael Thomas <mike at mtcc.com>
> To: Keith Medcalf <kmedcalf at dessus.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: LinkedIn password database compromised
> Message-ID: <4FE676DC.9000108 at mtcc.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 06/23/2012 05:52 PM, Keith Medcalf wrote:
>> Leo,
>>
>> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback).
>
> What is their leverage to extort? A web site just needs to make the
> client and server end agree on a scheme, and they control both ends.
> They can't force me to use their scheme any more than they can force
> me to not use Basic and use their scheme instead. Keep in mind that
> asymmetric keys do not imply certification, and asymmetric keys are
> cheap and plentiful -- as in a modest amount of CPU time these days.
>
> Mike
>
>> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
>>
>> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
>>
>> If it does not use self-generated unsigned keys, it will never fly.
>>
>> ---
>> () ascii ribbon campaign against html e-mail
>> /\ www.asciiribbon.org
>>
>>
>>> -----Original Message-----
>>> From: Leo Bicknell [mailto:bicknell at ufp.org]
>>> Sent: Wednesday, 20 June, 2012 15:39
>>> To: nanog at nanog.org
>>> Subject: Re: LinkedIn password database compromised
>>>
>>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
>>> wrote:
>>>> Key management: doing it right is hard and probably beyond most end users.
>>> I could not be in more violent disagreement.
>>>
>>> First time a user goes to sign up on a web page, the browser should
>>> detect it wants a key uploaded and do a simple wizard.
>>>
>>> - Would you like to create an online identity for logging into web
>>> sites? Yes, No, Import
>>>
>>> User says yes, it creates a key, asking for an e-mail address to
>>> identify it. Import to drag it in from some other program/format,
>>> No and you can't sign up.
>>>
>>> Browser now says "would you like to sign up for website 'foobar.com'",
>>> and if the user says "yes" it submits their public key including the
>>> e-mail they are going to use to log on. User doesn't even fill out
>>> a form at all.
>>>
>>> Web site still does the usual e-mail the user, click this link to verify
>>> you want to sign up thing.
>>>
>>> User goes back to web site later, browser detects "auth needed" and
>>> "public key foo" accepted, presents the cert, and the user is logged in.
>>>
>>> Notice that these steps _remove_ the user filling out forms to sign up
>>> for simple web sites, and filling out forms to log in. Anyone who's
>>> used cert-based auth at work is already familiar, the web site
>>> "magically" knows you. This is MUCH more user friendly.
>>>
>>> So the big magic here is the user has to click on "yes" to create a key
>>> and type in an e-mail once. That's it. There's no web of trust. No
>>> identity verification (a-la ssl). I'm talking a very SSH like system,
>>> but with more polish.
>>>
>>> Users would find it much more convenient and wonder why we ever used
>>> passwords, I think...
>>>
>>> --
>>> Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>> PGP keys at http://www.ufp.org/~bicknell/
>>
>>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 23 Jun 2012 22:02:25 -0700
> From: Kyle Creyts <kyle.creyts at gmail.com>
> To: nanog at nanog.org
> Subject: Re: How to fix authentication (was LinkedIn)
> Message-ID:
> <CA+TcGd_uhe5s161umexuC=3v2vaC31zFqV+aqEqjP0zYunab-g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I would suggest that multiple models be pursued (since each appears to have
> a champion) and that the market/drafting process will resolve the issue of
> which is better (which is okay by me: widespread adoption of any of the
> proposed models would advance the state of the norm; progress beats the
> snot out of stagnation in my book)
>
> My earlier replies were reprehensible. This is not a thread that should
> just be laughed off. Real progress may be occurring here, and at the least,
> good knowledge and discussion is accumulating in a way which may serve as a
> resource for the curious or concerned.
> On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>
>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush
>> wrote:
>>> there are no trustable third parties
>>
>> With a lot of transactions the second party isn't trustable, and
>> sometimes the first party isn't as well. :)
>>
>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher
>> Morrow wrote:
>>> note that yubico has models of auth that include:
>>> 1) using a third party
>>> 2) making your own party
>>> 3) HOTP on token
>>> 4) NFC
>>>
>>> they are a good company, trying to do the right thing(s)... They also
>>> don't necessarily want you to be stuck in the 'get your answer from
>>> another'
>>
>> Requirements of hardware or a third party are fine for the corporate
>> world, or sites that make enough money or have enough risk to invest
>> in security, like a bank.
>>
>> Requiring hardware for a site like Facebook or Twitter is right
>> out. Does not scale, can't ship to the guy in Pakistan or McMurdo
>> who wants to sign up. Trusting a third party becomes too expensive,
>> and too big of a business risk.
>>
>> There are levels of security here. I don't expect Facebook to take
>> the same security steps as my bank to move my money around. One
>> size does not fit all. Making it so a hacker can't get 10 million
>> login credentials at once is a quantum leap forward even if doing
>> so doesn't improve security in any other way.
>>
>> The perfect is the enemy of the good.
>>
>> --
>> Leo Bicknell - bicknell at ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 25 Jun 2012 00:41:26 -0300
> From: James Smith <james at smithwaysecurity.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Subject: EULAs
> Message-ID: <4FE7DDE6.7070606 at smithwaysecurity.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello,
>
> I was wondering if some one could contact me with regards to ISP's who
> share data to private companies if stated in their EULAs .
>
> --
> Sincerely;
>
>
> James Smith
> CEO, Security Analyst
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 25 Jun 2012 16:06:50 +0900
> From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
> To: nanog at nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <4FE80E0A.5020906 at necom830.hpcl.titech.ac.jp>
> Content-Type: text/plain; charset=ISO-2022-JP
>
> Justin M. Streiner wrote:
>
>> I see periodic upticks in the growth of the global v6 routing table (a
>> little over 9k prefixes at the moment - the v4 global view is about 415k
>> prefixes right now), which I would reasonably attribute an upswing in
>> networks getting initial assignments.
>
> As I already wrote:
>
> : That's not the point. The problem is that SRAMs scale well but
> : CAMs do not.
>
> it is a lot more difficult to quickly look up 1M routes
> with /48 than 2M routes with /24.
>
>> If anything, I see more of a
>> chance for the v4 routing table to grow more out of control, as v4
>> blocks get chopped up into smaller and smaller pieces in an ultimately
>> vain effort to squeeze a little more mileage out of IPv4.
>
> The routing table grows mostly because of multihoming,
> regardless of whether it is v4 or v6.
>
> The only solution is, IMO, to let multihomed sites have
> multiple prefixes inherited from their upper ISPs, still
> keeping the sites' ability to control loads between incoming
> multiple links.
>
> Masataka Ohta
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST)
> From: Tim Franklin <tim at pelican.org>
> To: nanog at nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <f3cc4bae-f05b-4320-82d0-191f4f6721ff at mail.pelican.org>
> Content-Type: text/plain; charset=utf-8
>
>> Even though it may be easy to make end systems and local
>> LANs v6 capable, rest, the center part, of the Internet
>> keep causing problems.
>
> Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result.
>
> Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made.
>
> But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today.
>
> Regards,
> Tim.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST)
> From: Tim Franklin <tim at pelican.org>
> To: nanog at nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <d76090e9-983b-420d-beb4-818ff97abdae at mail.pelican.org>
> Content-Type: text/plain; charset=utf-8
>
>> The only solution is, IMO, to let multihomed sites have
>> multiple prefixes inherited from their upper ISPs, still
>> keeping the sites' ability to control loads between incoming
>> multiple links.
>
> And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse).
>
> Regards,
> Tim.
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 25 Jun 2012 09:30:02 -0400
> From: AP NANOG <nanog at armoredpackets.com>
> To: nanog at nanog.org
> Subject: Re: How to fix authentication (was LinkedIn)
> Message-ID: <4FE867DA.8050400 at armoredpackets.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Kyle,
>
> I may be mistaken here, but I don't believe anyone is truly laughing the
> matter off.
>
> There may have been some remarks about second or third parties, but the
> fact does remain these are the areas which current concerns still lay.
>
> --
>
> Robert Miller
> (arch3angel)
>
> On 6/24/12 1:02 AM, Kyle Creyts wrote:
>> I would suggest that multiple models be pursued (since each appears to have
>> a champion) and that the market/drafting process will resolve the issue of
>> which is better (which is okay by me: widespread adoption of any of the
>> proposed models would advance the state of the norm; progress beats the
>> snot out of stagnation in my book)
>>
>> My earlier replies were reprehensible. This is not a thread that should
>> just be laughed off. Real progress may be occurring here, and at the least,
>> good knowledge and discussion is accumulating in a way which may serve as a
>> resource for the curious or concerned.
>> On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>>
>>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush
>>> wrote:
>>>> there are no trustable third parties
>>> With a lot of transactions the second party isn't trustable, and
>>> sometimes the first party isn't as well. :)
>>>
>>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher
>>> Morrow wrote:
>>>> note that yubico has models of auth that include:
>>>> 1) using a third party
>>>> 2) making your own party
>>>> 3) HOTP on token
>>>> 4) NFC
>>>>
>>>> they are a good company, trying to do the right thing(s)... They also
>>>> don't necessarily want you to be stuck in the 'get your answer from
>>>> another'
>>> Requirements of hardware or a third party are fine for the corporate
>>> world, or sites that make enough money or have enough risk to invest
>>> in security, like a bank.
>>>
>>> Requiring hardware for a site like Facebook or Twitter is right
>>> out. Does not scale, can't ship to the guy in Pakistan or McMurdo
>>> who wants to sign up. Trusting a third party becomes too expensive,
>>> and too big of a business risk.
>>>
>>> There are levels of security here. I don't expect Facebook to take
>>> the same security steps as my bank to move my money around. One
>>> size does not fit all. Making it so a hacker can't get 10 million
>>> login credentials at once is a quantum leap forward even if doing
>>> so doesn't improve security in any other way.
>>>
>>> The perfect is the enemy of the good.
>>>
>>> --
>>> Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>> PGP keys at http://www.ufp.org/~bicknell/
>>>
>
>
>
> End of NANOG Digest, Vol 53, Issue 105
> **************************************
More information about the NANOG
mailing list