[166307] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: comcast ipv6 PTR

daemon@ATHENA.MIT.EDU (Mark Andrews)
Wed Oct 16 09:13:44 2013

To: Valdis.Kletnieks@vt.edu
From: Mark Andrews <marka@isc.org>
In-reply-to: Your message of "Wed, 16 Oct 2013 08:59:21 -0400."
 <199168.1381928361@turing-police.cc.vt.edu>
Date: Thu, 17 Oct 2013 00:12:03 +1100
Cc: John Levine <johnl@iecc.com>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


In message <199168.1381928361@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu
 writes:
> 
> On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
> 
> > I can see this being done completely automatically by the CPE device.
> > It is trivial to code.  It just required ISP's to *allow* it to happen.
> 
> The rest of the plan looks OK at first glance.. However, step 0:
> 
> > * CPE generates a RSA key pair.  Stores this in non-volatile memory.
> >   [needs to be coded, no protocol work required]
> 
> has proven to be a lot harder to do in the field than one might expect, due
> to the very limited amount of entropy sources available to a CPE that Joe
> Sixpack just pulled out of a Best Buy shopping bag.  Witness the truly huge
> pile of CPE that generate horribly insecure weak self-signed certs for https.
> ...
 
Which is easily solvable when you design the CPE device to have
good sources of hardware randomness.  CPE devices are no longer
just routers which shuffle packets.  There are lots of activities
that CPE deviced do that require good randomness and it only costs
a couple of cents to add it the devices.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


home help back first fref pref prev next nref lref last post