[154087] in North American Network Operators' Group
Re: NANOG Digest, Vol 53, Issue 105
daemon@ATHENA.MIT.EDU (Gregg)
Mon Jun 25 15:19:44 2012
From: Gregg <spaceradio123@yahoo.com>
In-Reply-To: <mailman.1717.1340631027.68975.nanog@nanog.org>
Date: Mon, 25 Jun 2012 13:18:50 -0600
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
It really is possible to have a secure society that does not require identif=
ication 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 t=
hose go, sex follows. So, you could say, we have ourselves in a bit of a bin=
d 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@nanog.org wrote:
> Send NANOG mailing list submissions to
> nanog@nanog.org
>=20
> 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@nanog.org
>=20
> You can reach the person managing the list at
> nanog-owner@nanog.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>=20
>=20
> Today's Topics:
>=20
> 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)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Sat, 23 Jun 2012 18:52:10 -0600
> From: "Keith Medcalf" <kmedcalf@dessus.com>
> To: "Leo Bicknell" <bicknell@ufp.org>
> Cc: "nanog@nanog.org" <nanog@nanog.org>
> Subject: RE: LinkedIn password database compromised
> Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3@mail.dessus.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>=20
> Leo,
>=20
> This will never work. The "vested profiteers" will all get together and m=
ake it a condition that in order to use this method the user has to have "pu=
rchased" a "verified" key from them. Every site will use different profitee=
rs (probably whoever gives them the biggest kickback). You will end up payi=
ng thousands of dollars a year (as a user) to buy multiple keys from the pro=
fiteers, and provide them all sorts of private information in the process. T=
hey 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 l=
ong as it results in a profit. Some of this will get kicked back to partici=
pating web sites. Then there will be "affiliate programs" where any web sit=
e can "sign up" with the profiteers to "silently" do key exchanges without t=
he users consent so that more tracking information can be collected, for whi=
ch the participating affiliate web site will get a kickback. Browser vendor=
s will "assist" by making the whole process transparent. Contracts in restr=
aint of trade will be enforced by the profiteers to prevent any browser from=
using the "method" unless it is completely invisible to the user.
>=20
> Then (in the US) the fascist government will step in and require "registra=
tion" of issued keys along with the verified real-world identity linkage.
>=20
> If it does not use self-generated unsigned keys, it will never fly.
>=20
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>=20
>=20
>> -----Original Message-----
>> From: Leo Bicknell [mailto:bicknell@ufp.org]
>> Sent: Wednesday, 20 June, 2012 15:39
>> To: nanog@nanog.org
>> Subject: Re: LinkedIn password database compromised
>>=20
>> 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 user=
s.
>>=20
>> I could not be in more violent disagreement.
>>=20
>> 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.
>>=20
>> - Would you like to create an online identity for logging into web
>> sites? Yes, No, Import
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Web site still does the usual e-mail the user, click this link to verify
>> you want to sign up thing.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Users would find it much more convenient and wonder why we ever used
>> passwords, I think...
>>=20
>> --
>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>=20
>=20
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 2
> Date: Sat, 23 Jun 2012 19:14:31 -0600
> From: "Keith Medcalf" <kmedcalf@dessus.com>
> To: "Rich Kulawiec" <rsk@gsp.org>
> Cc: "nanog@nanog.org" <nanog@nanog.org>
> Subject: RE: LinkedIn password database compromised
> Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5@mail.dessus.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>=20
>=20
>> 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 justificatio=
ns
>> 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.
>=20
>> 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.
>=20
> This doesn't only apply to "SmartPhones". The most widely used Operating S=
ystem (by this I mean Windows) has been issued pre-compromised and has "inte=
ntionally implanted compromise via Vendor Update" for many years. It is onl=
y unethical when a non-American does it. The excuses and justifications are=
no different.
>=20
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>=20
>=20
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Sat, 23 Jun 2012 19:09:32 -0700
> From: Michael Thomas <mike@mtcc.com>
> To: Keith Medcalf <kmedcalf@dessus.com>
> Cc: "nanog@nanog.org" <nanog@nanog.org>
> Subject: Re: LinkedIn password database compromised
> Message-ID: <4FE676DC.9000108@mtcc.com>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>=20
> On 06/23/2012 05:52 PM, Keith Medcalf wrote:
>> Leo,
>>=20
>> This will never work. The "vested profiteers" will all get together and m=
ake it a condition that in order to use this method the user has to have "pu=
rchased" a "verified" key from them. Every site will use different profitee=
rs (probably whoever gives them the biggest kickback).
>=20
> 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.
>=20
> Mike
>=20
>> You will end up paying thousands of dollars a year (as a user) to buy mu=
ltiple keys from the profiteers, and provide them all sorts of private infor=
mation 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, f=
or whatever purpose, so long as it results in a profit. Some of this will g=
et kicked back to participating web sites. Then there will be "affiliate pr=
ograms" where any web site can "sign up" with the profiteers to "silently" d=
o key exchanges without the users consent so that more tracking information c=
an be collected, for which the participating affiliate web site will get a k=
ickback. Browser vendors will "assist" by making the whole process transpar=
ent. Contracts in restraint of trade will be enforced by the profiteers to p=
revent any browser from using the "method" unless it is completely invisible=
to the user.
>>=20
>> Then (in the US) the fascist government will step in and require "registr=
ation" of issued keys along with the verified real-world identity linkage.
>>=20
>> If it does not use self-generated unsigned keys, it will never fly.
>>=20
>> ---
>> () ascii ribbon campaign against html e-mail
>> /\ www.asciiribbon.org
>>=20
>>=20
>>> -----Original Message-----
>>> From: Leo Bicknell [mailto:bicknell@ufp.org]
>>> Sent: Wednesday, 20 June, 2012 15:39
>>> To: nanog@nanog.org
>>> Subject: Re: LinkedIn password database compromised
>>>=20
>>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegod=
a
>>> wrote:
>>>> Key management: doing it right is hard and probably beyond most end use=
rs.
>>> I could not be in more violent disagreement.
>>>=20
>>> 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.
>>>=20
>>> - Would you like to create an online identity for logging into web
>>> sites? Yes, No, Import
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Web site still does the usual e-mail the user, click this link to verify=
>>> you want to sign up thing.
>>>=20
>>> 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.=
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Users would find it much more convenient and wonder why we ever used
>>> passwords, I think...
>>>=20
>>> --
>>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>>> PGP keys at http://www.ufp.org/~bicknell/
>>=20
>>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 4
> Date: Sat, 23 Jun 2012 22:02:25 -0700
> From: Kyle Creyts <kyle.creyts@gmail.com>
> To: nanog@nanog.org
> Subject: Re: How to fix authentication (was LinkedIn)
> Message-ID:
> <CA+TcGd_uhe5s161umexuC=3D3v2vaC31zFqV+aqEqjP0zYunab-g@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>=20
> I would suggest that multiple models be pursued (since each appears to hav=
e
> 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)
>=20
> 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@ufp.org> wrote:
>=20
>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush=
>> wrote:
>>> there are no trustable third parties
>>=20
>> With a lot of transactions the second party isn't trustable, and
>> sometimes the first party isn't as well. :)
>>=20
>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christophe=
r
>> 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
>>>=20
>>> 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'
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> The perfect is the enemy of the good.
>>=20
>> --
>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>>=20
>=20
>=20
> ------------------------------
>=20
> Message: 5
> Date: Mon, 25 Jun 2012 00:41:26 -0300
> From: James Smith <james@smithwaysecurity.com>
> To: "nanog@nanog.org" <nanog@nanog.org>
> Subject: EULAs
> Message-ID: <4FE7DDE6.7070606@smithwaysecurity.com>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>=20
> Hello,
>=20
> I was wondering if some one could contact me with regards to ISP's who=20
> share data to private companies if stated in their EULAs .
>=20
> --=20
> Sincerely;
>=20
>=20
> James Smith
> CEO, Security Analyst
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 6
> Date: Mon, 25 Jun 2012 16:06:50 +0900
> From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
> To: nanog@nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp>
> Content-Type: text/plain; charset=3DISO-2022-JP
>=20
> Justin M. Streiner wrote:
>=20
>> I see periodic upticks in the growth of the global v6 routing table (a=20=
>> little over 9k prefixes at the moment - the v4 global view is about 415k=20=
>> prefixes right now), which I would reasonably attribute an upswing in=20
>> networks getting initial assignments.
>=20
> As I already wrote:
>=20
> : That's not the point. The problem is that SRAMs scale well but
> : CAMs do not.
>=20
> it is a lot more difficult to quickly look up 1M routes
> with /48 than 2M routes with /24.
>=20
>> If anything, I see more of a=20
>> chance for the v4 routing table to grow more out of control, as v4=20
>> blocks get chopped up into smaller and smaller pieces in an ultimately=20=
>> vain effort to squeeze a little more mileage out of IPv4.
>=20
> The routing table grows mostly because of multihoming,
> regardless of whether it is v4 or v6.
>=20
> 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.
>=20
> Masataka Ohta
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 7
> Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST)
> From: Tim Franklin <tim@pelican.org>
> To: nanog@nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <f3cc4bae-f05b-4320-82d0-191f4f6721ff@mail.pelican.org>
> Content-Type: text/plain; charset=3Dutf-8
>=20
>> 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.
>=20
> Really? My impression is that it's very much the edge that's hard - CE ro=
uters, 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 technolog=
ies. 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 i=
n my house again as a result.
>=20
> Systems can be a problem too - both in convincing IS people to change thin=
gs, in getting the budget for changes, and in finding all the dark places hi=
dden in the organisation where v4 assumptions are made.
>=20
> But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, w=
ith 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 i=
s being delivered and working fine today.
>=20
> Regards,
> Tim.
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 8
> Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST)
> From: Tim Franklin <tim@pelican.org>
> To: nanog@nanog.org
> Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Message-ID: <d76090e9-983b-420d-beb4-818ff97abdae@mail.pelican.org>
> Content-Type: text/plain; charset=3Dutf-8
>=20
>> 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.
>=20
> 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 t=
o consume an AS and some BGP space whether you like it or not - at least wit=
h 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 g=
et better or worse).
>=20
> Regards,
> Tim.
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 9
> Date: Mon, 25 Jun 2012 09:30:02 -0400
> From: AP NANOG <nanog@armoredpackets.com>
> To: nanog@nanog.org
> Subject: Re: How to fix authentication (was LinkedIn)
> Message-ID: <4FE867DA.8050400@armoredpackets.com>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>=20
> Kyle,
>=20
> I may be mistaken here, but I don't believe anyone is truly laughing the=20=
> matter off.
>=20
> There may have been some remarks about second or third parties, but the=20=
> fact does remain these are the areas which current concerns still lay.
>=20
> --=20
>=20
> Robert Miller
> (arch3angel)
>=20
> On 6/24/12 1:02 AM, Kyle Creyts wrote:
>> I would suggest that multiple models be pursued (since each appears to ha=
ve
>> a champion) and that the market/drafting process will resolve the issue o=
f
>> 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)
>>=20
>> 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 leas=
t,
>> 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@ufp.org> wrote:
>>=20
>>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bus=
h
>>> 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. :)
>>>=20
>>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christoph=
er
>>> 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
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> The perfect is the enemy of the good.
>>>=20
>>> --
>>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>>> PGP keys at http://www.ufp.org/~bicknell/
>>>=20
>=20
>=20
>=20
> End of NANOG Digest, Vol 53, Issue 105
> **************************************
