Re: Configuration Systems

[valdis . kletnieks]

On Thu, 07 Jun 2012 13:30:53 -1000, Paul Graydon said:

> Your original definition: "cloud" == "you rented a colo, but have no
> clue where".  I know exactly where my colo is.  I know exactly where my
> physical servers are.  If I run a private cloud on those servers and
> provision stuff there, I'll still know exactly where my colo is and I'll
> still know where my "cloud" infrastructure is deployed

I posit the thesis that if you know where it is, it's not really a cloud, it's
just a server farm with a severe attack of buzzwords. The whole point of
"cloud" is that you've made "where" Somebody Else's Problem - and if you know
where it is because you're still managing it yourself, it isn't an SEP.



pgpAU6Jk66RSE.pgp
Description: PGP signature

Re: Configuration Systems

[Owen DeLong]

By my count, we now have 3 engineers that have chimed in and somewhere between
5 and 6 definitions. Q.E. D.

Owen

On Jun 7, 2012, at 8:53 PM, Suresh Ramasubramanian wrote:

> It is like that supreme court judge who defined porn as "i know it
> when I see it"
> 
> On Fri, Jun 8, 2012 at 5:00 AM, Paul Graydon  wrote:
>> Your original definition: "cloud" == "you rented a colo, but have no clue
>> where".  I know exactly where my colo is.  I know exactly where my physical
>> servers are.  If I run a private cloud on those servers and provision stuff
>> there, I'll still know exactly where my colo is and I'll still know where my
>> "cloud" infrastructure is deployed
>> (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud)  Even that wiki
>> page doesn't quite go far enough in defining cloud, at least compared to
>> stuff people sell as "cloud" (as I said, cloud is a marketing term, not an
>> engineering one.  Its accuracy is negligible)
> 
> 
> 
> -- 
> Suresh Ramasubramanian (ops.li...@gmail.com)

Re: AAAA's for www.netflix.com

[Joly MacFie]

>
> Netflix may have created its own IPv6-specific domain which is responsible
> for almost a third of all IPv6 traffic. If this is the case it might not be
> in full compliance with the spirit of World IPv6 Day, as the aim should
> have been for Netflix to operate one single domain with both  records
> for IPv6 and A records for IPv4.


What about that?

j

On Fri, Jun 8, 2012 at 12:31 AM, David Temkin  wrote:
> On 6/7/12 10:23 PM, Daniel Roesen wrote:
>>
>> On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote:

 $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short
 wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
 $ dig @pdns3.ultradns.org www.netflix.com.  +norec +short
 dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
 $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec
 $

 Resolving www.netflix.com using ANY RRtype fails with an empty answer
 section in the DNS response.
>>>
>>> Which is just plain BROKEN.
>>
>> Yup.
>>
 This DNS trickery seems to be from the "taking a shower, trying not
 to get wet" department. And has adverse effects in corner cases. While
 playing around, I had periods of time where I couldn't resolve the FQDN
 at all, possibly due some caching of the empty response.
>>>
>>> It's not DNS trickery.
>>
>> The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=.
>> I'm not sure what's the goal of that is, but it's 4am here so I have an
>> excuse of not seeing the light. :)
>>
>> Best regards,
>> Daniel
>>
> We've confirmed that UltraDNS had "additional" issues caused by the push
> that they fixed for the previously reported problem.  We are actively
> engaged with them to come to a resolution.
>
> -Dave
>



-- 
---
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--
-

Re: AAAA's for www.netflix.com

[David Temkin]

On 6/7/12 10:23 PM, Daniel Roesen wrote:

On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote:

$ dig @pdns3.ultradns.org www.netflix.com. A +norec +short
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
$ dig @pdns3.ultradns.org www.netflix.com.  +norec +short
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
$ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec
$

Resolving www.netflix.com using ANY RRtype fails with an empty answer
section in the DNS response.

Which is just plain BROKEN.

Yup.


This DNS trickery seems to be from the "taking a shower, trying not
to get wet" department. And has adverse effects in corner cases. While
playing around, I had periods of time where I couldn't resolve the FQDN
at all, possibly due some caching of the empty response.

It's not DNS trickery.

The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=.
I'm not sure what's the goal of that is, but it's 4am here so I have an
excuse of not seeing the light. :)

Best regards,
Daniel

We've confirmed that UltraDNS had "additional" issues caused by the push 
that they fixed for the previously reported problem.  We are actively 
engaged with them to come to a resolution.


-Dave

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Karl Auer]

On Fri, 2012-06-08 at 03:08 +, Dave Hart wrote:
> networks.  With IPv4, ARP presents not only a network capacity issue,
> but also a host capacity issue as every node expends software
> resources processing every broadcast ARP.  With ND, only a tiny
> fraction of hosts expend any software capacity processing a given
> multicast packet, thanks to ethernet NIC's hardware filtering of
> received multicasts -- with or without multicast-snooping switches.

So we are actually sort of agreeing. That's a relief :-) However,
preventing packets getting to the NICs *at all* is a pretty big win,
because even if a clever NIC can prevent a host CPU being interrupted,
the packet was still wasting bandwidth on the path to the NIC.

I would go so far as to say that MLD snooping makes the NIC side of
things almost irrelevant. Almost :-)

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Re: Configuration Systems

[Suresh Ramasubramanian]

It is like that supreme court judge who defined porn as "i know it
when I see it"

On Fri, Jun 8, 2012 at 5:00 AM, Paul Graydon  wrote:
> Your original definition: "cloud" == "you rented a colo, but have no clue
> where".  I know exactly where my colo is.  I know exactly where my physical
> servers are.  If I run a private cloud on those servers and provision stuff
> there, I'll still know exactly where my colo is and I'll still know where my
> "cloud" infrastructure is deployed
> (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud)  Even that wiki
> page doesn't quite go far enough in defining cloud, at least compared to
> stuff people sell as "cloud" (as I said, cloud is a marketing term, not an
> engineering one.  Its accuracy is negligible)



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Dave Hart]

On Fri, Jun 8, 2012 at 12:48 AM, Karl Auer  wrote:
> Yes - whether with ARP or ND, any node has to filter out the packets
> that do not apply to it (whether it's done by the NIC or the host CPU is
> another question, not relevant here).

It is relevant to the question of the scalability of large L2
networks.  With IPv4, ARP presents not only a network capacity issue,
but also a host capacity issue as every node expends software
resources processing every broadcast ARP.  With ND, only a tiny
fraction of hosts expend any software capacity processing a given
multicast packet, thanks to ethernet NIC's hardware filtering of
received multicasts -- with or without multicast-snooping switches.

> The original post posited that ND could cause as much traffic as ARP. My
> point is that it probably doesn't, because the ND packets will only be
> seen on the specific switch ports belonging to those nodes that are
> listening to the relevant multicast groups, and only those nodes will
> actually receive the ND packets. In contrast to ARP, which is broadcast,
> always, to all nodes, and thus goes out every switch port in the
> broadcast domain.
>
> This is pretty much the *point* of using multicast instead of broadcast.

I agree.

Re: AAAA's for www.netflix.com

[Daniel Roesen]

On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote:
> > $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short
> > wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
> > $ dig @pdns3.ultradns.org www.netflix.com.  +norec +short
> > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
> > $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec
> > $
> > 
> > Resolving www.netflix.com using ANY RRtype fails with an empty answer
> > section in the DNS response.
> 
> Which is just plain BROKEN.

Yup.

> > This DNS trickery seems to be from the "taking a shower, trying not
> > to get wet" department. And has adverse effects in corner cases. While
> > playing around, I had periods of time where I couldn't resolve the FQDN
> > at all, possibly due some caching of the empty response.
> 
> It's not DNS trickery.

The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=.
I'm not sure what's the goal of that is, but it's 4am here so I have an
excuse of not seeing the light. :)

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: AAAA's for www.netflix.com

[Mark Andrews]

In message <20120608011910.ga16...@srv03.cluenet.de>, Daniel Roesen writes:
> On Thu, Jun 07, 2012 at 04:43:41PM -0700, David Temkin wrote:
> > What do you mean?  www.netflix.com is dual stacked, which represents
> > availability of our website (and PC/Mac streaming clients) to100% of our
> > users who have IPv6.
> 
> The zero TTL on the CNAME an  RRs makes www.netflix.com
> zero-stacked at least for some resolvers:
> 
> $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short
> wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
> $ dig @pdns3.ultradns.org www.netflix.com.  +norec +short
> dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
> $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec
> $
> 
> Resolving www.netflix.com using ANY RRtype fails with an empty answer
> section in the DNS response.

Which is just plain BROKEN.
 
> This DNS trickery seems to be from the "taking a shower, trying not
> to get wet" department. And has adverse effects in corner cases. While
> playing around, I had periods of time where I couldn't resolve the FQDN
> at all, possibly due some caching of the empty response.

It's not DNS trickery.  It's not reading the RFC or doing any testing
for common cases.  Not every query has type A.  Way too many load
balancers get the answers to anything other than A queries wrong.
If your load balancer get answers to queries other than A wrong
demand your money back.

This sort of !@$E in authoritative servers makes it hard for recursive
servers to do the right thing.

pandora.tv servers are the poster child for getting it wrong currently.

* They don't set "aa" as per RFC 103[45].
  (If you set it in the query they clear it.)
* They don't clear "ad" as per RFC 103[45].
* They have extra data after the DNS response.
* They send back malformed responses to EDNS queries.

bsdi# dig9 ns pandora.tv @N1.pandora.tv +noedns +norec

; <<>> DiG 9.9.1-P1 <<>> ns pandora.tv @N1.pandora.tv +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153
;; flags: qr ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Messages has 27 extra bytes at end

;; QUESTION SECTION:
;pandora.tv.IN  NS

;; ANSWER SECTION:
pandora.tv. 300 IN  NS  N1.pandora.tv.
pandora.tv. 300 IN  NS  N2.pandora.tv.
pandora.tv. 300 IN  NS  N15.pandora.tv.
pandora.tv. 300 IN  NS  N16.pandora.tv.
pandora.tv. 300 IN  NS  N17.pandora.tv.

;; Query time: 385 msec
;; SERVER: 61.111.8.236#53(61.111.8.236)
;; WHEN: Fri Jun  8 11:56:22 2012
;; MSG SIZE  rcvd: 143

bsdi# dig9 ns pandora.tv @N1.pandora.tv +edns=0 +norec
;; Got bad packet: FORMERR
143 bytes
cd c9 80 a0 00 01 00 05 00 00 00 01 07 70 61 6e  .pan
64 6f 72 61 02 74 76 00 00 02 00 01 c0 0c 00 02  dora.tv.
00 01 00 00 01 2c 00 05 02 4e 31 c0 0c c0 0c 00  .,...N1.
02 00 01 00 00 01 2c 00 05 02 4e 32 c0 0c c0 0c  ..,...N2
00 02 00 01 00 00 01 2c 00 06 03 4e 31 35 c0 0c  ...,...N15..
c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e 31 36  .,...N16
c0 0c c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e  ...,...N
31 37 c0 0c 00 00 00 00 00 00 00 00 00 00 00 00  17..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
bsdi# 

Mark

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

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Karl Auer]

On Fri, 2012-06-08 at 11:08 +1000, Mark Andrews wrote:
> > This is pretty much the *point* of using multicast instead of
> broadcast.
> 
> The point of multicast is be able to reject traffic sooner rather
> than later.

Well - yes - and my description was of how, when properly configured and
on the right hardware, unwanted multicast IPv6 packets do not even reach
the NIC.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Re: AAAA's for www.netflix.com

[Daniel Roesen]

On Fri, Jun 08, 2012 at 03:19:10AM +0200, Daniel Roesen wrote:
> The zero TTL on the CNAME an  RRs makes www.netflix.com
> zero-stacked at least for some resolvers:

Correction... I don't really know wether the zero TTL on the CNAME
provokes problems, but not returning any RR on ANY RRtype queries seems
to do.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: AAAA's for www.netflix.com

[Daniel Roesen]

On Thu, Jun 07, 2012 at 04:43:41PM -0700, David Temkin wrote:
> What do you mean?  www.netflix.com is dual stacked, which represents
> availability of our website (and PC/Mac streaming clients) to100% of our
> users who have IPv6.

The zero TTL on the CNAME an  RRs makes www.netflix.com
zero-stacked at least for some resolvers:

$ dig @pdns3.ultradns.org www.netflix.com. A +norec +short
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
$ dig @pdns3.ultradns.org www.netflix.com.  +norec +short
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
$ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec
$

Resolving www.netflix.com using ANY RRtype fails with an empty answer
section in the DNS response.

This DNS trickery seems to be from the "taking a shower, trying not
to get wet" department. And has adverse effects in corner cases. While
playing around, I had periods of time where I couldn't resolve the FQDN
at all, possibly due some caching of the empty response.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Mark Andrews]

In message <1339116492.2754.162.camel@karl>, Karl Auer writes:
> 
> --=-ebOzahzuucm9tstf70zM
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote:
> > Karl, you seem to fail to understand how ethernet NICs are implemented
> > in the real world.  Ignoring the optional (but common) promiscuous
> > mode support and various offloading, IPv4 ARP is sent as ethernet
> > broadcast and the NIC hardware and driver is in no position to filter
> > -- it must be done by the IP stack.  In contrast, ND is sent as
> > ethernet multicast which are filtered by receivers in hardware.
> > Whether or not the switches are smart enough to filter is an
> > implementation decision that has no bearing on the requirement to
> > filter in the NIC hardware.
> 
> I'm the first to admit that I often don't know stuff. One good reason to
> be on the NANOG mailing list! But in this case...
> 
> Yes - whether with ARP or ND, any node has to filter out the packets
> that do not apply to it (whether it's done by the NIC or the host CPU is
> another question, not relevant here).
> 
> But in a properly switched IPv6 network, many/most ND packets do not
> arrive at most nodes' network interfaces at all, so those nodes have no
> filtering work to do. Yes, the nodes that DO get a packet - those
> listening on the relevant multicast group, often a solicited node
> multicast group - DO need to filter out the NDs that don't apply to
> them, but the point is that a vastly reduced number of nodes are thus
> inconvenienced compared.
> 
> The original post posited that ND could cause as much traffic as ARP. My
> point is that it probably doesn't, because the ND packets will only be
> seen on the specific switch ports belonging to those nodes that are
> listening to the relevant multicast groups, and only those nodes will
> actually receive the ND packets. In contrast to ARP, which is broadcast,
> always, to all nodes, and thus goes out every switch port in the
> broadcast domain.
> 
> This is pretty much the *point* of using multicast instead of broadcast.

The point of multicast is be able to reject traffic sooner rather
than later.  Running IPv6 with a nic that doesn't support several
multicast addresses is a real pain which I know from experience.
It can however be done.

> Regards, K.
> 
> --=20
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Karl Auer]

On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote:
> Karl, you seem to fail to understand how ethernet NICs are implemented
> in the real world.  Ignoring the optional (but common) promiscuous
> mode support and various offloading, IPv4 ARP is sent as ethernet
> broadcast and the NIC hardware and driver is in no position to filter
> -- it must be done by the IP stack.  In contrast, ND is sent as
> ethernet multicast which are filtered by receivers in hardware.
> Whether or not the switches are smart enough to filter is an
> implementation decision that has no bearing on the requirement to
> filter in the NIC hardware.

I'm the first to admit that I often don't know stuff. One good reason to
be on the NANOG mailing list! But in this case...

Yes - whether with ARP or ND, any node has to filter out the packets
that do not apply to it (whether it's done by the NIC or the host CPU is
another question, not relevant here).

But in a properly switched IPv6 network, many/most ND packets do not
arrive at most nodes' network interfaces at all, so those nodes have no
filtering work to do. Yes, the nodes that DO get a packet - those
listening on the relevant multicast group, often a solicited node
multicast group - DO need to filter out the NDs that don't apply to
them, but the point is that a vastly reduced number of nodes are thus
inconvenienced compared.

The original post posited that ND could cause as much traffic as ARP. My
point is that it probably doesn't, because the ND packets will only be
seen on the specific switch ports belonging to those nodes that are
listening to the relevant multicast groups, and only those nodes will
actually receive the ND packets. In contrast to ARP, which is broadcast,
always, to all nodes, and thus goes out every switch port in the
broadcast domain.

This is pretty much the *point* of using multicast instead of broadcast.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


signature.asc
Description: This is a digitally signed message part

Re: LinkedIn password database compromised

[Randy Bush]

>> this is a feature, not a bug.  you should be explaining to them why
>> they should never type passwords on another's keyboard, log on to
>> anything from an internet cafe, ...
> And this is where you lose the user.

actually, not.  it's like safe sex, an anology they understand.  you may
be tempted over the line, but you know you may regret it for the rest of
your shortened life.

of course, having net on tablets and ip phones helps.

randy

Re: LinkedIn password database compromised

[Sean Harlow]

On Jun 7, 2012, at 19:24, Randy Bush wrote:

> this is a feature, not a bug.  you should be explaining to them why they
> should never type passwords on another's keyboard, log on to anything
> from an internet cafe, ...

And this is where you lose the user.  It doesn't matter that you're entirely 
right about the security risks of doing so, but real-world security is all 
about finding a balance with usability.

Situations where the data really does need to be secure are great for mandating 
public key authentication, as you point out it raises a significant technical 
barrier to the unskilled user preventing them from even attempting to access it 
from anywhere they shouldn't.  That said, I doubt anyone but the most insane of 
security geeks are using it for their personal email.  If the value to the 
person of being able to access their data from $random_computer exceeds the 
perceived risk, they'll do it if they can.

---
Sean Harlow
s...@seanharlow.info

RE: sporadic IPv6 connectivity to forums.comcast.com

[Brzozowski, John]

We are investigating.

 Original Message 
 From: Casey Deccio 
 Sent: Thu, 07/06/2012 18:47
 To: nanog@nanog.org
 CC:
 Subject: sporadic IPv6 connectivity to forums.comcast.com


I'm seeing sporadic IPv6 connectivity issues to forums.comcast.com:

casey@rome$ curl -I6 forums.comcast.com
HTTP/1.1 200 OK
Date: Thu, 07 Jun 2012 21:48:37 GMT
[snip...]

casey@rome$ curl -I6 forums.comcast.com
curl: (7) couldn't connect to host

casey@rome:~$ traceroute6 forums.comcast.com
traceroute to forums.comcast.com (2620:6a:8000:4::11) from
2001:470:21:31::adf5:492a, port 33434, from port 42309, 30 hops max, 60
byte packets
 1  2001:470:21:31::1 (2001:470:21:31::1)  1.713 ms  1.922 ms  2.039 ms
 2  2001:470:1f:b::1 (2001:470:1f:b::1)  10.575 ms  3.343 ms  3.147 ms
 3  10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1)  6.855 ms
 4.225 ms  4.252 ms
 4  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  4.271 ms
 14.442 ms  4.469 ms
 5  sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1)  5.385 ms  4.669 ms
 4.434 ms
 6  internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2)  4.702
ms  4.803 ms  4.848 ms
 7  border1-bbnet2.sje.pnap.net (2600:c02:0:102::1:1)  5.175 ms  25.023 ms
 4.808 ms
 8  lithiumtechinc-2.border1.sje.pnap.net (2600:c02:1001:3::2)  9.445 ms
 8.120 ms  7.804 ms
 9  2620:6a:8000:4::11 (2620:6a:8000:4::11)  5.491 ms  5.712 ms  5.873 ms

casey@rome:~$ traceroute6 forums.comcast.com
traceroute to forums.comcast.com (2620:6a:8000:4::11) from
2001:470:21:31::adf5:492a, port 33434, from port 42311, 30 hops max, 60
byte packets
 1  2001:470:21:31::1 (2001:470:21:31::1)  1.574 ms  1.514 ms  1.856 ms
 2  2001:470:1f:b::1 (2001:470:1f:b::1)  2.882 ms  3.089 ms  14.462 ms
 3  10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1)  4.573 ms
 4.466 ms  6.683 ms
 4  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  4.525 ms
 10.401 ms  4.748 ms
 5  sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1)  4.794 ms  4.931 ms
 4.406 ms
 6  internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2)  4.837
ms  4.922 ms  4.527 ms
 7  border1-bbnet1.sje.pnap.net (2600:c02:0:101::1:1)  5.884 ms  4.626 ms
 5.037 ms
 8  border3-bbnet2.sje.pnap.net (2600:c02:0:102::1:3)  3157.850 ms !H
 3270.481 ms !H  3226.411 ms !H

Is this perhaps a routing issue?

Casey

Re: AAAA's for www.netflix.com

[David Temkin]

Joly,

What do you mean?  www.netflix.com is dual stacked, which represents
availability of our website (and PC/Mac streaming clients) to100% of our
users who have IPv6.

-Dave

On Thursday, June 7, 2012, Joly MacFie wrote:

> well, something appears to be working..
>
> http://www.betterbroadbandblog.com/2012/06/world-ipv6-daywe-have-liftoff/
>
> Netflix moved up to second in the IPv6 list – as noted above, Netflix has
> been rolling out IPv6 coverage over the last few weeks.  Interestingly, it
> appears as if Netflix may have created its own IPv6-specific domain which
> is responsible for almost a third of all IPv6 traffic. If this is the case
> it might not be in full compliance with the spirit of World IPv6 Day, as
> the aim should have been for Netflix to operate one single domain with both
>  records for IPv6 and A records for IPv4.
>
> On Thu, Jun 7, 2012 at 6:04 PM, Mark Andrews >
> wrote:
>
> >
> > In message <20120607165818.ga30...@srv03.cluenet.de >,
> Daniel Roesen
> > writes:
> > > On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote:
> > > > Just to close the loop on this - UltraDNS has an issue with CNAMEs
> and
> > > > their Directional DNS service.  We (Netflix) have applied a
> workaround
> > and
> > > > it appears stable.
> > >
> > > Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't
> > > improve visibility of the , but decreased it.
> >
> > TTL's of zero don't help.  The A query has a TTL of 3600 in the
> > response the  query has a zero TTL.  This is rocket science.
> > This isn't hard to do correctly.  How to handle CNAMEs has been
> > specified 1/4 of a century.
> >
> > > Best regards,
> > > Daniel
> > >
> > > --
> > > CLUE-RIPE -- Jabber: d...@cluenet.de  -- dr@IRCnet --
> PGP: 0xA85C8AA0
> > >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> >
>
>
> --
> ---
> Joly MacFie  218 565 9365 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com
>  http://pinstand.com - http://punkcast.com
>  VP (Admin) - ISOC-NY - http://isoc-ny.org
> --
> -
>

Re: Configuration Systems

[Paul Graydon]

On 06/07/2012 12:59 PM, valdis.kletni...@vt.edu wrote:

On Thu, 07 Jun 2012 12:12:09 -1000, Paul Graydon said:

what cloud is you've also got to go into the realms of private clouds
(using, for example, openstack), on your own infrastructure in your own
datacenter.

Same definition.  The user I've provisioned still has no idea where I 
provisioned him.


That's before you even start delving into PaaS, SaaS "clouds" etc.

Still the same definition.  You have no idea where you're provisioned from.
Your original definition: "cloud" == "you rented a colo, but have no 
clue where".  I know exactly where my colo is.  I know exactly where my 
physical servers are.  If I run a private cloud on those servers and 
provision stuff there, I'll still know exactly where my colo is and I'll 
still know where my "cloud" infrastructure is deployed 
(http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud)  Even that 
wiki page doesn't quite go far enough in defining cloud, at least 
compared to stuff people sell as "cloud" (as I said, cloud is a 
marketing term, not an engineering one.  Its accuracy is negligible)


Paul

Re: LinkedIn password database compromised

[Randy Bush]

> Plus, now you have the problem of users not being able to login to
> their favourite websites when they're using a friend's computer,
> internet cafe, etc, unless they've remembered to bring a copy of their
> private key with them.

this is a feature, not a bug.  you should be explaining to them why they
should never type passwords on another's keyboard, log on to anything
from an internet cafe, ...

randy

Re: AAAA's for www.netflix.com

[Joly MacFie]

well, something appears to be working..

http://www.betterbroadbandblog.com/2012/06/world-ipv6-daywe-have-liftoff/

Netflix moved up to second in the IPv6 list – as noted above, Netflix has
been rolling out IPv6 coverage over the last few weeks.  Interestingly, it
appears as if Netflix may have created its own IPv6-specific domain which
is responsible for almost a third of all IPv6 traffic. If this is the case
it might not be in full compliance with the spirit of World IPv6 Day, as
the aim should have been for Netflix to operate one single domain with both
 records for IPv6 and A records for IPv4.

On Thu, Jun 7, 2012 at 6:04 PM, Mark Andrews  wrote:

>
> In message <20120607165818.ga30...@srv03.cluenet.de>, Daniel Roesen
> writes:
> > On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote:
> > > Just to close the loop on this - UltraDNS has an issue with CNAMEs and
> > > their Directional DNS service.  We (Netflix) have applied a workaround
> and
> > > it appears stable.
> >
> > Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't
> > improve visibility of the , but decreased it.
>
> TTL's of zero don't help.  The A query has a TTL of 3600 in the
> response the  query has a zero TTL.  This is rocket science.
> This isn't hard to do correctly.  How to handle CNAMEs has been
> specified 1/4 of a century.
>
> > Best regards,
> > Daniel
> >
> > --
> > CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>


-- 
---
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--
-

Re: LinkedIn password database compromised

[Mark Andrews]

In message <4fd0ae52.20...@alter3d.ca>, Peter Kristolaitis writes:
> On 6/7/2012 9:22 AM, James Snow wrote:
> > On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
> >> Imaging signing up for a site by putting in your email and pasting
> >> your public key.
> > Yes! Yes! Yes!
> >
> > I've been making this exact argument for about a year. It even retains
> > the same "email a link" reset mechanism when someone needs to reset
> > their key.
> >
> > A common counter-argument is, "But ordinary Internet users won't
> > understand SSH keys." They don't need to! The idea is easily explained
> > via a lock-and-key metaphor that people already understand. The UI for
> > walking users through key creation is easily imagined.
> >
> >
> > -Snow
> 
> Oh yeah, I can just imagine that "lock and key" conversation now...
> 
> "Imagine if the website has a lock on it, and you tell them what key you =
> 
> want to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of=20
> the other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"

No.  The correct metaphor is I have a key and a bunch of locks keyed to that
lock.  I give them a lock to install which only the key I have can open.
 
> The other problem with this approach is that, as bad as trusting remote=20
> sites to do security properly is, I'm not sure that putting a "one key=20
> to rule them all" on users' machines is that much better, given the=20
> average user's penchant for installing malware on their machine because=20
> "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the=20
> time...   I suspect we'd see a huge wave of malware whose sole purpose=20
> is to steal public keys (and you KNOW users won't password-protect their =
> private keys!).

Actually it is a big win.  You now have to compromise millions of machines
to get millions of keys rather than a couple of machines to get millions
of passwords.

>   Plus, now you have the problem of users not being able =
> to login to their favourite websites when they're using a friend's=20
> computer, internet cafe, etc, unless they've remembered to bring a copy=20
> of their private key with them.

That is a real issue.
 
> I think public key auth for websites is a great idea for geeks who=20
> understand the benefits, limitations and security concerns, but I have=20
> serious doubts that it would hold up when subjected to the "idiot test".
> 
> - Pete
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Configuration Systems

[valdis . kletnieks]

On Thu, 07 Jun 2012 12:12:09 -1000, Paul Graydon said:
> what cloud is you've also got to go into the realms of private clouds
> (using, for example, openstack), on your own infrastructure in your own
> datacenter.

Same definition.  The user I've provisioned still has no idea where I 
provisioned him.

> That's before you even start delving into PaaS, SaaS "clouds" etc.

Still the same definition.  You have no idea where you're provisioned from.


pgpnwIDsuQuwb.pgp
Description: PGP signature

Re: LinkedIn password database compromised

[Randy Bush]

>> the 'single sign on' i encourage for the end using human beings i
>> support is 1password and its ilk.  it provides the user with one
>> sign-on yet strongly encourages separation of identities and strong
>> passwords for sites.
> 
> Local repository of passwords, aggregation in a way. Right? Encrypted?
> Open source?

local repository good, i.e. the user owns and controls.  others can not
associate the user's different identities.  (again, run the ghostery
browser add-on)

encrypted good, a bit protected from loss of laptop, a 'maid attack',
etc.

open source sure would be good

randy

sporadic IPv6 connectivity to forums.comcast.com

[Casey Deccio]

I'm seeing sporadic IPv6 connectivity issues to forums.comcast.com:

casey@rome$ curl -I6 forums.comcast.com
HTTP/1.1 200 OK
Date: Thu, 07 Jun 2012 21:48:37 GMT
[snip...]

casey@rome$ curl -I6 forums.comcast.com
curl: (7) couldn't connect to host

casey@rome:~$ traceroute6 forums.comcast.com
traceroute to forums.comcast.com (2620:6a:8000:4::11) from
2001:470:21:31::adf5:492a, port 33434, from port 42309, 30 hops max, 60
byte packets
 1  2001:470:21:31::1 (2001:470:21:31::1)  1.713 ms  1.922 ms  2.039 ms
 2  2001:470:1f:b::1 (2001:470:1f:b::1)  10.575 ms  3.343 ms  3.147 ms
 3  10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1)  6.855 ms
 4.225 ms  4.252 ms
 4  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  4.271 ms
 14.442 ms  4.469 ms
 5  sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1)  5.385 ms  4.669 ms
 4.434 ms
 6  internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2)  4.702
ms  4.803 ms  4.848 ms
 7  border1-bbnet2.sje.pnap.net (2600:c02:0:102::1:1)  5.175 ms  25.023 ms
 4.808 ms
 8  lithiumtechinc-2.border1.sje.pnap.net (2600:c02:1001:3::2)  9.445 ms
 8.120 ms  7.804 ms
 9  2620:6a:8000:4::11 (2620:6a:8000:4::11)  5.491 ms  5.712 ms  5.873 ms

casey@rome:~$ traceroute6 forums.comcast.com
traceroute to forums.comcast.com (2620:6a:8000:4::11) from
2001:470:21:31::adf5:492a, port 33434, from port 42311, 30 hops max, 60
byte packets
 1  2001:470:21:31::1 (2001:470:21:31::1)  1.574 ms  1.514 ms  1.856 ms
 2  2001:470:1f:b::1 (2001:470:1f:b::1)  2.882 ms  3.089 ms  14.462 ms
 3  10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1)  4.573 ms
 4.466 ms  6.683 ms
 4  10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2)  4.525 ms
 10.401 ms  4.748 ms
 5  sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1)  4.794 ms  4.931 ms
 4.406 ms
 6  internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2)  4.837
ms  4.922 ms  4.527 ms
 7  border1-bbnet1.sje.pnap.net (2600:c02:0:101::1:1)  5.884 ms  4.626 ms
 5.037 ms
 8  border3-bbnet2.sje.pnap.net (2600:c02:0:102::1:3)  3157.850 ms !H
 3270.481 ms !H  3226.411 ms !H

Is this perhaps a routing issue?

Casey

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Dave Hart]

On Thu, Jun 7, 2012 at 10:14 PM, Karl Auer  wrote:
> On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote:
>> Bzzt.  With ARP, every IPv4 node on the link indicates each ARP packet
>> to the OS.  With ND, only those nodes sharing the same last 24 bits of
>> the IPv6 address indicate the packet up the stack.  The rest of the
>> IPv6 nodes filter the multicast in the NIC.
>
> Still not quite correct :-)
>
> The "filtering" is done by a MLD-aware switch, which will send multicast
> packets only to nodes that are listening to the appropriate multicast
> group. The filtering you describe is pretty much what ARP does - ALL
> nodes receive the packet, all but one ignore it. It depends on the
> platform whether the CPU that does the ignoring is just in the NIC or is
> in the node itself.

Karl, you seem to fail to understand how ethernet NICs are implemented
in the real world.  Ignoring the optional (but common) promiscuous
mode support and various offloading, IPv4 ARP is sent as ethernet
broadcast and the NIC hardware and driver is in no position to filter
-- it must be done by the IP stack.  In contrast, ND is sent as
ethernet multicast which are filtered by receivers in hardware.
Whether or not the switches are smart enough to filter is an
implementation decision that has no bearing on the requirement to
filter in the NIC hardware.

Cheers,
Dave Hart

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Karl Auer]

On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote:
> Bzzt.  With ARP, every IPv4 node on the link indicates each ARP packet
> to the OS.  With ND, only those nodes sharing the same last 24 bits of
> the IPv6 address indicate the packet up the stack.  The rest of the
> IPv6 nodes filter the multicast in the NIC.

Still not quite correct :-)

The "filtering" is done by a MLD-aware switch, which will send multicast
packets only to nodes that are listening to the appropriate multicast
group. The filtering you describe is pretty much what ARP does - ALL
nodes receive the packet, all but one ignore it. It depends on the
platform whether the CPU that does the ignoring is just in the NIC or is
in the node itself.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Re: Configuration Systems

[Paul Graydon]

On 06/07/2012 11:49 AM, valdis.kletni...@vt.edu wrote:

On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said:


This is a hard problem to solve. Not the least of the difficulties is the fact 
that
if you ask 50 engineers to define "Cloud", you will get at least 100 definitions
many of which are incompatible to the point of mutually exclusive.

"cloud" == "you rented in a colo, but have no clue where".
Only if you're talking IaaS, and that's only a very vague and not 
necessarily accurate description of that too.  When you start describing 
what cloud is you've also got to go into the realms of private clouds 
(using, for example, openstack), on your own infrastructure in your own 
datacenter.  That's before you even start delving into PaaS, SaaS 
"clouds" etc.


"Cloud" is a marketing term, not an engineering one.

Paul

Re: LinkedIn password database compromised

[David Walker]

On 08/06/2012, Matthew Kaufman  wrote:
> It also allows them to sign anyone they want as someone pretending to be
> you, but with a different key pair.

You're exacly correct but in this case I don't think CAs are necessary
and probably detrimental so it's moot.

Currently I don't care at all if somebody joins YouTube with my name
or whatever and has a password I know nothing about. Well I do care a
little.
The point is that there's nothing sensitive about a username/password
combination for these type of accounts.
We don't care.
I'm sure I've communicated on the internet with President Obama and Johnny Cash.
If there's ever any doubt and something nefarious is going on there
are other methods.

I don't think anyone's suggesting that this is appropriate for
anything sensitive.
In short nothing changes at all other than swapping certificates for passwords.

If my bank wants to start doing it then they'll have to keep doing
what they're doing now and use other channels to verify me at
establishment, i.e. I'll have to walk into a branch and verify myself
and give them a USB stick with my certificate or whatever ...

>
> Just like the DMV could, if it wanted to (or was ordered to) issue a drivers
> license with my name and DL number but an FBI agent's photo and thumbprint
> associated.
>
> You'd want your logins to be at sites that only trusted CAs that you trusted
> to not do this... for HTTPS we're already way over that line I'm afraid.
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 7, 2012, at 1:18 PM, Owen DeLong  wrote:
>
>> A proper CA does not have your business or personal keys, they merely
>> sign them and attest to the fact that they actually represent you. You
>> are
>> free to seek and obtain such validation from any and as many parties as
>> you see fit.
>>
>> At no point should any CA be given your private key data. They merely
>> use their private key to encrypt a hash of your public key and other data
>> to indicate that your private key is bound to your other data.
>>
>> You trust DMV/Passport Agency/etc. to validate your identity in the form
>> of your government issued ID credentials, right?
>>
>> That doesn't give DMV/Passport Agency/etc. control over your face, but,
>> it does allow them to indicate to others that your face is tied to your
>> name, date of birth, etc.
>>
>> Owen
>>
>> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>>
>>> I gotta agree with Aaron here. What would be my motivation to "trust" an
>>> open and public infrastructure? With my business or personal keys?
>>>
>>> -Hammer-
>>>
>>> "I was a normal American nerd"
>>> -Jack Herer
>>>
>>>
>>>
>>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
 On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
>> Heck no to X.509.  We'd run into the same issue we have right now--a
>> select group of companies charging users to prove their identity.
> Not if enough of us get behind CACERT.
 Yet again, another org (free or not) that is holding my identity
 hostage.
 Would you give cacert your SSH key and use them to log in to your
 Linux servers?  I'd bet most *nix admins would shout "hell no!"

 So why would you make them the gateway for your online identity?

 -A


>>
>>
>
>

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Karl Auer]

On Thu, 2012-06-07 at 16:42 -0400, Ricky Beam wrote:
> On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote:
> > a) DAD only happens when an IPv6 node is starting up. ARP happens
> > whenever a node needs to talk to another node that it hasn't seen in
> > while.
> 
> DAD is a special case of ND.  It happens every time the system selects
> an address. (i.e. startup with non-SLAAC address, and when privacy
> extensions generates an address.)

Er - OK. I should have said "happens when an address is assigned to an
interface". It is still, however, way less traffic than ARP, which was
my point. Possible exception - a network where everyone is using privacy
addresses.

> > b) DAD only goes to solicited node multicast addresses
> 
> This assumes a network of devices that do multicast filtering,
> correctly.

Yes, it does. It assumes a properly provisioned and configured IPv6
network. While that may not be common now, it will become more common.
And it is a self-correcting problem - people who don't want lots of
noise will implement their networks correctly, those who don't care will
do as they wish. No change there :-)

BTW, I'm assuming here that by "multicast filtering" you mean "switching
that properly snoops on MLD and sends multicast packets only to the
correct listeners".

> > c) Similarly, ND (the direct equivalent of ARP) goes only to
> solicited node multicast addresses, ARP goes to every node on the
> link.
> 
> Effectively the same as broadcast in the IPv6 world.  If everyone is  
> running IPv6, then everyone will see the packet. (things not running
> ipv6 can filter it out, but odds are it'll be put on the cable.)

On this point I think you are wrong. Except for router advertisements,
most NDP packets are sent to a solicited node multicast address, and so
do NOT go to all nodes. It is "the same as broadcast" only in a network
with switches that do not do MLD snooping.

> > So I'm not sure how DAD traffic would exceed ARP traffic.
> 
> I wouldn't expect it to.

Nor would I - which was the point of my response to an original poster
who said it might.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Re: Configuration Systems

[Owen DeLong]

On Jun 7, 2012, at 2:49 PM, valdis.kletni...@vt.edu wrote:

> On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said:
> 
>> This is a hard problem to solve. Not the least of the difficulties is the 
>> fact that
>> if you ask 50 engineers to define "Cloud", you will get at least 100 
>> definitions
>> many of which are incompatible to the point of mutually exclusive.
> 
> "cloud" == "you rented in a colo, but have no clue where".


Congratulations of being one of the first in the room to offer a candidate
definition.

So... What's your second definition?

If you don't have a second definition, you're just asking someone else to 
provide
3 or more.

Owen

Re: AAAA's for www.netflix.com

[Mark Andrews]

In message <20120607165818.ga30...@srv03.cluenet.de>, Daniel Roesen writes:
> On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote:
> > Just to close the loop on this - UltraDNS has an issue with CNAMEs and 
> > their Directional DNS service.  We (Netflix) have applied a workaround and 
> > it appears stable.
> 
> Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't
> improve visibility of the , but decreased it.

TTL's of zero don't help.  The A query has a TTL of 3600 in the
response the  query has a zero TTL.  This is rocket science.
This isn't hard to do correctly.  How to handle CNAMEs has been
specified 1/4 of a century.

> Best regards,
> Daniel
> 
> -- 
> CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: LinkedIn password database compromised

[Owen DeLong]

No argument about that at all.

Owen

On Jun 7, 2012, at 2:26 PM, Matthew Kaufman wrote:

> It also allows them to sign anyone they want as someone pretending to be you, 
> but with a different key pair.
> 
> Just like the DMV could, if it wanted to (or was ordered to) issue a drivers 
> license with my name and DL number but an FBI agent's photo and thumbprint 
> associated.
> 
> You'd want your logins to be at sites that only trusted CAs that you trusted 
> to not do this... for HTTPS we're already way over that line I'm afraid.
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)
> 
> On Jun 7, 2012, at 1:18 PM, Owen DeLong  wrote:
> 
>> A proper CA does not have your business or personal keys, they merely
>> sign them and attest to the fact that they actually represent you. You are
>> free to seek and obtain such validation from any and as many parties as
>> you see fit.
>> 
>> At no point should any CA be given your private key data. They merely
>> use their private key to encrypt a hash of your public key and other data
>> to indicate that your private key is bound to your other data.
>> 
>> You trust DMV/Passport Agency/etc. to validate your identity in the form
>> of your government issued ID credentials, right?
>> 
>> That doesn't give DMV/Passport Agency/etc. control over your face, but,
>> it does allow them to indicate to others that your face is tied to your
>> name, date of birth, etc.
>> 
>> Owen
>> 
>> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
>> 
>>> I gotta agree with Aaron here. What would be my motivation to "trust" an 
>>> open and public infrastructure? With my business or personal keys?
>>> 
>>> -Hammer-
>>> 
>>> "I was a normal American nerd"
>>> -Jack Herer
>>> 
>>> 
>>> 
>>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
 On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
>> Heck no to X.509.  We'd run into the same issue we have right now--a
>> select group of companies charging users to prove their identity.
> Not if enough of us get behind CACERT.
 Yet again, another org (free or not) that is holding my identity hostage.
 Would you give cacert your SSH key and use them to log in to your
 Linux servers?  I'd bet most *nix admins would shout "hell no!"
 
 So why would you make them the gateway for your online identity?
 
 -A
 
 
>> 
>> 

Re: LinkedIn password database compromised

[David Walker]

On 07/06/2012, Lynda  wrote:
> Sorry to be the bearer of such bad tidings.

I'm a very amateur cryptologist so some of this is new to me:
"Any organization using SHA-1 without salting user passwords is
running a great risk -- much higher than they should," said Per
Thorsheim, chief information security advisor at Norwegian IT services
company EVRY. "We've seen this time and time again. This is not good
practice. Salt should be a minimum."
http://money.cnn.com/2012/06/06/technology/linkedin-password-hack/

This, however, is all too commonplace:
"We take the security of our members very seriously."
http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/

This is the only security item they have and it's mission critical right?
The issues are well understood and highly publicized.
The procedures are simple.
Taking a casual interest in security pretty much precludes mistakes here.
I'm not fooled at all.

http://press.linkedin.com/node/1192

The current system can work if applied correctly but time and again
we're seeing failure from service providers to follow the dots.
As I mentioned I'm no expert but I don't think widening the circle of
trust is the correct answer regardless of the technology. There's no
technology shortfall here.
Self signed certificates does sound great and for most purposes,
certainly in this case, fulfills all the requirements. There's no need
to verify anything about me is correct other than to tie my
authentication to my account. If I fail to meet the TOS then the plug
is easily pulled and any further activity can be dealt with as it
currently is by other means. I think there's enough risk in bringing
in a CA and so little advantage that it's wrong.

As far as moving the cryptographic responsibility from the service
provider to us - I'm all for it. They've been telling us for some time
now they'd rather not do that stuff.
I'd much rather have control and introduce something a little sleeker.
As far as users go, if they have to learn it to get on FaceSpace then
they'll learn it - that's a given.
There's no reason for it not to be optional anyway.

To all the people who've figured this out, my hat's off.

I'm very suspicious of any mention of a browser being involved in this
process though.
Shifiting some software responsibility to the client probably brings
new/different danger anyway but probably the last piece of goop that
should be involved is a browser.
That's anecdotal aversion but I'll stand by it.

> Please note that LinkedIn has weighed in with a carefully worded blog post:
>
> http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/
>
> Further details:
> 1. The leak took place on June 4
> 2. LinkedIn was using unsalted SHA-1 for their password store.
> 3. FYI, there are two lists. The second one appears to be from eHarmony.
> Unsalted MD5 used there.
> 4. The posted passwords are believed to be ones the cracker wanted help
> with, i.e., they have significantly more already cracked.
>
> Apparently phishing emails are already active in the wild based on the
> crack:
>
> http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-linkedin-breach-for-phishing-attacks/
>
> In other words, if you have a LinkedIn account, expect that the password
> has been stolen. Go change your password now. If you used that password
> elsewhere, you know the routine. In addition, as has been pointed out
> elsewhere, there's no sign LI has fixed the problem. Expect that the
> password you change it to will also be compromised.
>
> :-(
>
> --
> A picture is worth 10K words -- but only those to describe
> the picture.  Hardly any sets of 10K words can be adequately
> described with pictures.
>
>
>

Re: Configuration Systems

[valdis . kletnieks]

On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said:

> This is a hard problem to solve. Not the least of the difficulties is the 
> fact that
> if you ask 50 engineers to define "Cloud", you will get at least 100 
> definitions
> many of which are incompatible to the point of mutually exclusive.

"cloud" == "you rented in a colo, but have no clue where".


pgprIGlDVsQc7.pgp
Description: PGP signature

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Owen DeLong]

On Jun 7, 2012, at 1:27 PM, Ricky Beam wrote:

> On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church  
> wrote:
>> Does anyone know the reason /64 was proposed as the size for all L2 domains?
> 
> There is one, and only one, reason for the ::/64 split: SLAAC.  IPv6 is a 
> classless addressing system.  You can make your LAN ::/117 if you want to; 
> SLAAC will not work there.
> 
Nope...

There's also ND and the solicited node address.

> The reason the requirement is (currently) 64 is to accomodate EUI-64 hardware 
> addresses -- firewire, bluetooth, fibre channel, etc.  Originally, SLAAC was 
> designed for ethernet and its 48bit hardware address. (required LAN mask was 
> ::/80.)  The purpose wasn't to put the whole internet into one LAN.  It was 
> to make address selection "brainless", esp. for embeded systems with limited 
> memory/cpu/etc... they can form an address by simply appending their MAC to 
> the prefix, and be 99.9% sure it won't be in use. (i.e. no DAD required.) 
>  However, that was optimizing a problem that never existed -- existing tiny 
> systems of the day were never destined to have an IPv6 stack, "modern" IPv6 
> hardware can select an address and perform DAD efficiently in well under 1K. 
> (which is noise vs. the size of the rest of the IPv6 stack.)

Modern embedded IPv6 systems in short order will have IPv6 implemented in the 
chip ala the Wizard W5100 chip that is very popular for IPv4 in embedded 
systems and micro-controllers today.

> SLAAC has been a flawed idea from the first letter... if for no other reason 
> than it makes people think "64bit network + 64bit host" -- and that is 
> absolutely wrong. (one cannot make such assumptions about networks they do 
> not control. it's even worse when people design hardware thinking that.)

While one cannot assume 64+64 on networks you don't control and CIDR is the 
rule for IPv6, having a common 64+64 subnet size widely deployed has a number 
of advantages.

I am interested to hear what people are using in lieu of ND and ARP on NBMA 
and/or BMA multipoint IPv6 networks with netmasks longer than /64.

Owen

Re: LinkedIn password database compromised

[Michael Hallgren]

Hi Randy,

Le jeudi 07 juin 2012 à 10:03 -0700, Randy Bush a écrit :
> hi etaoin,
> 
> > I still don't want single sign on.  Not anywhere.
> 
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks.  essentially it means that the 'identiry provider' owns
> your identity.  i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.

I agree.

> 
> the 'single sign on' i encourage for the end using human beings i
> support is 1password and its ilk.  it provides the user with one sign-on
> yet strongly encourages separation of identities and strong passwords
> for sites.
> 

Local repository of passwords, aggregation in a way. Right? Encrypted?
Open source?

> add to that, something such as ghostery for your browser, and you have a
> small chance of actually preserving your identity and minimizing cross-
> site tracking.
> 
> randy

mh

> 

Re: LinkedIn password database compromised

[Matthew Kaufman]

It also allows them to sign anyone they want as someone pretending to be you, 
but with a different key pair.

Just like the DMV could, if it wanted to (or was ordered to) issue a drivers 
license with my name and DL number but an FBI agent's photo and thumbprint 
associated.

You'd want your logins to be at sites that only trusted CAs that you trusted to 
not do this... for HTTPS we're already way over that line I'm afraid.

Matthew Kaufman

(Sent from my iPhone)

On Jun 7, 2012, at 1:18 PM, Owen DeLong  wrote:

> A proper CA does not have your business or personal keys, they merely
> sign them and attest to the fact that they actually represent you. You are
> free to seek and obtain such validation from any and as many parties as
> you see fit.
> 
> At no point should any CA be given your private key data. They merely
> use their private key to encrypt a hash of your public key and other data
> to indicate that your private key is bound to your other data.
> 
> You trust DMV/Passport Agency/etc. to validate your identity in the form
> of your government issued ID credentials, right?
> 
> That doesn't give DMV/Passport Agency/etc. control over your face, but,
> it does allow them to indicate to others that your face is tied to your
> name, date of birth, etc.
> 
> Owen
> 
> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:
> 
>> I gotta agree with Aaron here. What would be my motivation to "trust" an 
>> open and public infrastructure? With my business or personal keys?
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
> Heck no to X.509.  We'd run into the same issue we have right now--a
> select group of companies charging users to prove their identity.
 Not if enough of us get behind CACERT.
>>> Yet again, another org (free or not) that is holding my identity hostage.
>>> Would you give cacert your SSH key and use them to log in to your
>>> Linux servers?  I'd bet most *nix admins would shout "hell no!"
>>> 
>>> So why would you make them the gateway for your online identity?
>>> 
>>> -A
>>> 
>>> 
> 
> 

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Dave Hart]

On Thu, Jun 7, 2012 at 8:42 PM, Ricky Beam  wrote:
> On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer  wrote:
>>
>> c) Similarly, ND (the direct equivalent of ARP) goes only to solicited
>> node multicast addresses, ARP goes to every node on the link.
>
> Effectively the same as broadcast in the IPv6 world.  If everyone is running
> IPv6, then everyone will see the packet. (things not running ipv6 can filter
> it out, but odds are it'll be put on the cable.)

Bzzt.  With ARP, every IPv4 node on the link indicates each ARP packet
to the OS.  With ND, only those nodes sharing the same last 24 bits of
the IPv6 address indicate the packet up the stack.  The rest of the
IPv6 nodes filter the multicast in the NIC.

Cheers,
Dave Hart

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Ricky Beam]

On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer  wrote:

a) DAD only happens when an IPv6 node is starting up. ARP happens
whenever a node needs to talk to another node that it hasn't seen in
while.


DAD is a special case of ND.  It happens every time the system selects an  
address. (i.e. startup with non-SLAAC address, and when privacy extensions  
generates an address.)



b) DAD only goes to solicited node multicast addresses, i.e., only to
those nodes that share the same last 24 bits as the target address. ARP
goes to every node on the link (broadcast).


This assumes a network of devices that do multicast filtering, correctly.   
This is not a good assumption even in large enterprises.  Common  
residential gear usually doesn't understand multicast at all. (unless  
you're a uverse tv customer using ethernet and paid close attention to  
your hardware.)



c) Similarly, ND (the direct equivalent of ARP) goes only to solicited
node multicast addresses, ARP goes to every node on the link.


Effectively the same as broadcast in the IPv6 world.  If everyone is  
running IPv6, then everyone will see the packet. (things not running ipv6  
can filter it out, but odds are it'll be put on the cable.)



So I'm not sure how DAD traffic would exceed ARP traffic.


I wouldn't expect it to.  Looking at the output of my 3745, it fires 3  
ND's at startup and is then silent. (TWC has no IPv6 on my node, but v4  
ARP broadcasts amount to ~16K/s)


--Ricky

Re: LinkedIn password database compromised

[-Hammer-]

Thank you for educating without insulting. Always professional Owen. 
It's appreciated.


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 6/7/2012 3:18 PM, Owen DeLong wrote:

A proper CA does not have your business or personal keys, they merely
sign them and attest to the fact that they actually represent you. You are
free to seek and obtain such validation from any and as many parties as
you see fit.

At no point should any CA be given your private key data. They merely
use their private key to encrypt a hash of your public key and other data
to indicate that your private key is bound to your other data.

You trust DMV/Passport Agency/etc. to validate your identity in the form
of your government issued ID credentials, right?

That doesn't give DMV/Passport Agency/etc. control over your face, but,
it does allow them to indicate to others that your face is tied to your
name, date of birth, etc.

Owen

On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:


I gotta agree with Aaron here. What would be my motivation to "trust" an open 
and public infrastructure? With my business or personal keys?

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:

On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong   wrote:

Heck no to X.509.  We'd run into the same issue we have right now--a
select group of companies charging users to prove their identity.

Not if enough of us get behind CACERT.

Yet again, another org (free or not) that is holding my identity hostage.
Would you give cacert your SSH key and use them to log in to your
Linux servers?  I'd bet most *nix admins would shout "hell no!"

So why would you make them the gateway for your online identity?

-A

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Ricky Beam]

On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church   
wrote:
Does anyone know the reason /64 was proposed as the size for all L2  
domains?


There is one, and only one, reason for the ::/64 split: SLAAC.  IPv6 is a  
classless addressing system.  You can make your LAN ::/117 if you want to;  
SLAAC will not work there.


The reason the requirement is (currently) 64 is to accomodate EUI-64  
hardware addresses -- firewire, bluetooth, fibre channel, etc.   
Originally, SLAAC was designed for ethernet and its 48bit hardware  
address. (required LAN mask was ::/80.)  The purpose wasn't to put the  
whole internet into one LAN.  It was to make address selection  
"brainless", esp. for embeded systems with limited memory/cpu/etc... they  
can form an address by simply appending their MAC to the prefix, and be  
99.9% sure it won't be in use. (i.e. no DAD required.)  However, that  
was optimizing a problem that never existed -- existing tiny systems of  
the day were never destined to have an IPv6 stack, "modern" IPv6 hardware  
can select an address and perform DAD efficiently in well under 1K. (which  
is noise vs. the size of the rest of the IPv6 stack.)


SLAAC has been a flawed idea from the first letter... if for no other  
reason than it makes people think "64bit network + 64bit host" -- and that  
is absolutely wrong. (one cannot make such assumptions about networks they  
do not control. it's even worse when people design hardware thinking that.)


--Ricky

Re: LinkedIn password database compromised

[Owen DeLong]

A proper CA does not have your business or personal keys, they merely
sign them and attest to the fact that they actually represent you. You are
free to seek and obtain such validation from any and as many parties as
you see fit.

At no point should any CA be given your private key data. They merely
use their private key to encrypt a hash of your public key and other data
to indicate that your private key is bound to your other data.

You trust DMV/Passport Agency/etc. to validate your identity in the form
of your government issued ID credentials, right?

That doesn't give DMV/Passport Agency/etc. control over your face, but,
it does allow them to indicate to others that your face is tied to your
name, date of birth, etc.

Owen

On Jun 7, 2012, at 1:04 PM, -Hammer- wrote:

> I gotta agree with Aaron here. What would be my motivation to "trust" an open 
> and public infrastructure? With my business or personal keys?
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:
>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
 Heck no to X.509.  We'd run into the same issue we have right now--a
 select group of companies charging users to prove their identity.
>>> Not if enough of us get behind CACERT.
>> Yet again, another org (free or not) that is holding my identity hostage.
>> Would you give cacert your SSH key and use them to log in to your
>> Linux servers?  I'd bet most *nix admins would shout "hell no!"
>> 
>> So why would you make them the gateway for your online identity?
>> 
>> -A
>> 
>> 

Re: LinkedIn password database compromised

[Owen DeLong]

On Jun 7, 2012, at 12:37 PM, Aaron C. de Bruyn wrote:

> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
>>> Heck no to X.509.  We'd run into the same issue we have right now--a
>>> select group of companies charging users to prove their identity.
>> 
>> Not if enough of us get behind CACERT.
> 
> Yet again, another org (free or not) that is holding my identity hostage.
> Would you give cacert your SSH key and use them to log in to your
> Linux servers?  I'd bet most *nix admins would shout "hell no!"
> 
> So why would you make them the gateway for your online identity?
> 
> -A

HuH?

They don't hold my identity hostage. They sign my identity. That's it.

I create the certificate and the private key. They never receive the private 
key.
They merely provide a mechanism by which trusted parties can verify and then
attest that I am, indeed, who I claim to be.

Would I consider using my X.509 certificate as an authentication method for
my linux servers? Not at this time for the simple reason that the combinations
of expiry and the UI complexities in doing so make it significantly less
convenient than my SSH keys.

However, if it were made to be equally convenient with SSH keys, then, I
don't see a problem with it.

Owen

Re: LinkedIn password database compromised

[Owen DeLong]

On Jun 7, 2012, at 10:03 AM, Randy Bush wrote:

> hi etaoin,
> 
>> I still don't want single sign on.  Not anywhere.
> 
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks.  essentially it means that the 'identiry provider' owns
> your identity.  i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.
> 
If single sign-on is done right, then YOU are the identity provider and YOU
own your identity. It does, however, potentially enable cross-site tracking.


Owen

Re: LinkedIn password database compromised

[-Hammer-]

I gotta agree with Aaron here. What would be my motivation to "trust" an 
open and public infrastructure? With my business or personal keys?


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote:

On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:

Heck no to X.509.  We'd run into the same issue we have right now--a
select group of companies charging users to prove their identity.

Not if enough of us get behind CACERT.

Yet again, another org (free or not) that is holding my identity hostage.
Would you give cacert your SSH key and use them to log in to your
Linux servers?  I'd bet most *nix admins would shout "hell no!"

So why would you make them the gateway for your online identity?

-A

Re: LinkedIn password database compromised

[Owen DeLong]

On Jun 7, 2012, at 9:29 AM, Bruch, Mark wrote:

> I rarely reply to threads. However the point of interest that is missed is 
> "Not supported anymore because Microsoft says so". So Microsoft starts 
> putting out systems at one per year and not supporting old ones because they 
> "Have you over a barrel"? 
> 
> Tell your daughter she can't get married? You haven't bought your new 
> operating system this year, and "backward compatible" is a thing of the past?
> 
> Then it is $119.00 per year on top of that (maybe)? 
> 
> Let's say Microsoft promised business to the PC building companies and 
> decides that an operating system per year is only supported on new equipment? 
> The cost to vote could be thousands per year. Only the rich can afford to 
> vote?
> 
> The point is that you have to be careful about where you go with technology 
> and who controls it. I am sure there are people who would love to see voting 
> as a "can you afford it" right.

Nah... They've obviated the need with superPACs and other mechanisms for 
purchasing the politicians we vote for much more cost effectively than 
purchasing the elections themselves.

Owen

> 
> -Original Message-
> From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com] 
> Sent: Thursday, June 07, 2012 11:10 AM
> To: Jared Mauch
> Cc: Nanog
> Subject: Re: LinkedIn password database compromised
> 
> On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch  wrote:
>> I'm imagining my mother trying this, or trying to help her change it after 
>> the hard drive dies and the media in the safe deposit box doesn't read 
>> anymore.
> 
> I would think it's fairly simple.
> What if she forgot her existing password?  Most sites have a 'reset password' 
> link they e-mail you.
> A browser extension 'helper' would simply generate a new key and let you 
> reset your password.  Maybe the helper could be dumbed down enough to 
> automatically handle the password reset screen and automatically POST the new 
> key to the reset page.
> 
> I'm sure it could be done transparently enough that our mothers wouldn't need 
> to think twice about it.
> 
> Heck--the 'helper' could probably even back up your SSH key off-site sorta 
> like LastPass does.  And if your private key is actually password protected, 
> it's slightly less useless if the off-site backup company were compromised.
> 
> The only downfall is how do you get access to your e-mail account?
> (Google already calls my cell and/or home phone if I request access without 
> using my password.)
> 
> I agree there are stumbling blocks, and it wouldn't be perfect--but it seems 
> like it would be much better than the alternative we have now.
> People using the same password on multiple sites, passwords written down, 
> dumb website operators not salting their hashes, etc...
> 
> Also, thanks for the great secondary DNS service.  ;)
> 
> -A
> 

Re: LinkedIn password database compromised

[Aaron C. de Bruyn]

On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong  wrote:
>> Heck no to X.509.  We'd run into the same issue we have right now--a
>> select group of companies charging users to prove their identity.
>
> Not if enough of us get behind CACERT.

Yet again, another org (free or not) that is holding my identity hostage.
Would you give cacert your SSH key and use them to log in to your
Linux servers?  I'd bet most *nix admins would shout "hell no!"

So why would you make them the gateway for your online identity?

-A

Re: LinkedIn password database compromised

[Owen DeLong]

On Jun 7, 2012, at 6:36 AM, Peter Kristolaitis wrote:

> On 6/7/2012 9:22 AM, James Snow wrote:
>> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
>>> Imaging signing up for a site by putting in your email and pasting
>>> your public key.
>> Yes! Yes! Yes!
>> 
>> I've been making this exact argument for about a year. It even retains
>> the same "email a link" reset mechanism when someone needs to reset
>> their key.
>> 
>> A common counter-argument is, "But ordinary Internet users won't
>> understand SSH keys." They don't need to! The idea is easily explained
>> via a lock-and-key metaphor that people already understand. The UI for
>> walking users through key creation is easily imagined.
>> 
>> 
>> -Snow
> 
> Oh yeah, I can just imagine that "lock and key" conversation now...
> 
> "Imagine if the website has a lock on it, and you tell them what key you want 
> to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of the 
> other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"
> 

Wrong approach...

"Imagine if the website has a lock created by each user. The user creates the 
lock by giving the web site their "lock template". Once you give them the "lock 
template", only your key will open that lock."

(Lock template = public key, key = private key)

"No, the lock template won't open the other copies of the lock template. Only 
the key will open the lock template, but, the key will open all the lock 
templates. It's just like having all the locks on your house "keyed alike". I 
can't take the lock off the front door and use it to open the back door, 
neither can the lock template given to one website be used to unlock your 
account at another website."

> The other problem with this approach is that, as bad as trusting remote sites 
> to do security properly is, I'm not sure that putting a "one key to rule them 
> all" on users' machines is that much better, given the average user's 
> penchant for installing malware on their machine because 
> "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time...   I 
> suspect we'd see a huge wave of malware whose sole purpose is to steal public 
> keys (and you KNOW users won't password-protect their private keys!).   Plus, 
> now you have the problem of users not being able to login to their favourite 
> websites when they're using a friend's computer, internet cafe, etc, unless 
> they've remembered to bring a copy of their private key with them.

Yeah, there is that problem as well. Personally, I'd like to see someone 
produce what amounts to a mini-HSM such as a USB-dongle that will contain but 
never emit the private key, and perform one of the following functions, given 
the right one-time password (which could be produced either by display on the 
dongle, or, by a mobile app):

1.  Emit public key.
2.  Encrypt challenge response or other data using private key.
3.  Create new keypair.

This would provide the benefits of 2-factor authentication along with the ease 
of the proposed SSH-key mechanism. The key wouldn't be accessible to malware 
and in order to exploit the key, the malware would have to convince the user to 
enter their one-time password and/or
would be required to beat the legitimate application to the request (in which 
case, the legitimate application's request would fail making the failure 
obvious to the user).

> I think public key auth for websites is a great idea for geeks who understand 
> the benefits, limitations and security concerns, but I have serious doubts 
> that it would hold up when subjected to the "idiot test".

I think that there is a lot of UI work to be done in this area, but, that it 
can actually be made safe and effective for lay-persons.

After all, if Blizzard can get a bunch of their players using 2-factor tokens 
for authentication, this can't really be that much harder.

Owen

Re: LinkedIn password database compromised

[Owen DeLong]

On Jun 6, 2012, at 11:14 PM, Aaron C. de Bruyn wrote:

> On Wed, Jun 6, 2012 at 8:34 PM, Jimmy Hess  wrote:
>> Which digital id architecture should web sites implement, and what's
>> going to make them  all agree on one SSO system   and move from the
>> current state to one of the possible solutions though?  :)
>> 
>>A TLS + Client-Side X.509 Certificate  for every user.
> 
> Heck no to X.509.  We'd run into the same issue we have right now--a
> select group of companies charging users to prove their identity.
> 

Not if enough of us get behind CACERT.

Non-profit organization providing fee certificates based on web of trust
model.

http://www.cacert.org

For any of you in the bay area and/or who encounter me in my various
travels, I am an CACERT top-level notary.

Personally, I like the SSH model and simply giving the web-site your
public key at sign-up, but, there are issues with that as well...

If your private key is compromised, how do you notify all of the web-sites
that it needs to be revoked?

Owen

Re: Configuration Systems

[Owen DeLong]

On Jun 6, 2012, at 7:58 PM, Andrew Latham wrote:

> Jonathan
> 
> That is the exact question I have asked myself many times.  All of the
> major players in Configuration management have a "client" program that
> must run and at times requires some libraries that are newer than the
> platforms a company may need to support or that clients may wish
> supported.  Another issue is the secure communication  over a
> proprietary or SSH connection and not allowing secured VLANs or other
> services like RSH and Telnet over a point to point connection.
> 

I would argue that not allowing telnet/rsh in favor of requiring SSH is a good 
thing.

As to the client program, so long as the system makes the client available via
open source and/or publishes the required client API, you should be able to
work around any library issues or system age issues by developing your own
client component.

> Also you will find that the demand for cloud systems and the complex
> languages used in the "Configuration Management Systems" do not easily
> translate to the existing and developing cloud infrastructure.

This is a hard problem to solve. Not the least of the difficulties is the fact 
that
if you ask 50 engineers to define "Cloud", you will get at least 100 definitions
many of which are incompatible to the point of mutually exclusive.

Owen

> 
> and stuff...
> 
> 
> On Wed, Jun 6, 2012 at 10:52 PM, Jonathan Herbert  wrote:
>> Hi Andrew,
>> 
>> Out of curiosity, why are you reinventing the wheel here?
>> 
>> Don't take this the wrong way- I'm just curious why you're building
>> something new. What does Enablement do that the other technologies you've
>> mentioned doesn't?
>> 
>> Jonathan
>> 
>> 
>> On Wed, Jun 6, 2012 at 10:49 PM, Andrew Latham  wrote:
>>> 
>>> Lurker speaking... beware...
>>> 
>>> I have been talking with some folks from various industries about
>>> configuration systems ala Bcfg2, Puppet, Chef, and others.  Many of
>>> them care far too much about the current nodes configuration status as
>>> some admin had logged in and changed something.  I am authoring a
>>> system called Enablement that uses what ever technology needed (ssh,
>>> telnet over admin vlan, rsh, etc...) to push a planned system/config
>>> to the device.  Monitoring and auditing are all the same at the moment
>>> as we need historical data on when a service or port started and
>>> stopped offering its planned or unplanned service.  For a meeting
>>> Thursday I am looking forward to the future of configuring systems.
>>> My idea is push + netblock scanning of services.  With stacks for
>>> clouds we can startup and shut down nodes easy.  Would a bend over
>>> backwards config reader for all the "Configuration Management Systems"
>>> be the best medium ground from the service provider point of view?
>>> 
>>> Enablement  Send another man to fight on the front line.
>>> 
>>> --
>>> ~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~
>>> 
>> 
> 
> 
> 
> -- 
> ~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

Re: LinkedIn password database compromised

[valdis . kletnieks]

On Thu, 07 Jun 2012 13:33:59 -0400, Marshall Eubanks said:

> Maybe so, but anonymous entries on linkedin seems like a zen koan,
> beyond the powers of my simple mind.

There's a distinction between anonymous and pseudonymous.  I'm
certainly not the former, but to all but maybe a dozen or two NANOG'ers, I'm
pretty much the latter - somebody who always posts from the same
identity, but they've never actually personally verified the identity.


pgpMw8h2dHyBh.pgp
Description: PGP signature

Re: LinkedIn password database compromised

[Randy Bush]

>>> so... now that this can is open, has anyone looked at:
>>>   
>>
>> yep.  yet another bucket of identity slime wanting to resell my
>> identity.
> 
> maybe? they don't seem to want to be the 'identity provider' directly
> though, or rather they point out that your corporation could be your
> identity provider (or anyone else you might trust) they simply sell
> the enabling software/tech.

so they provide tools to indentity resellers.  the folk their software
enables are still *reselling* MY identity.

my point is that it is MY identity.  there are tools, such as 1password,
which enable me to control MY identity and yet have the effect of single
sign-on.

and i believe it is important that mom and pop retain control of their
identities.

randy

AT&T Bucks IPv6 Trend

[Henry Linneweh]

Since AT&T has not said much about ipv6, here is their position on it and how 
they 
intend to deploy

http://www.lightreading.com/blog.asp?blog_sectionid=847&doc_id=221739&f_src=lrdailynewsletter


-Henry

Re: LinkedIn password database compromised

[Marshall Eubanks]

On Thu, Jun 7, 2012 at 1:30 PM, Tei  wrote:
> The problem:
> - Modern internet users must have lots of different login/passwords around
> the internet.  Most of then in easy-to-break poorly-patched poorly-managed
> servers,  like linkedin.
>
> The solution:
> -  Reduce the number of authentication.  Allow anonymous posting in more
> sites.
>
> Imagine this.   I post something on the blog  "yadaydayda". I give my email
> and nothing else.   The blog software sends me a email to confirm the post.
> I click on it, and the post is published.
>
> The real problem is that nowdays everybody and his dog want a password, and
> a password is expensive for the user.  The internet need more anonymous
> ways to publish content.

Maybe so, but anonymous entries on linkedin seems like a zen koan,
beyond the powers of my simple mind.

Regards
Marshall

>
>
> --
> --
> ℱin del ℳensaje.

Re: LinkedIn password database compromised

[Christopher Morrow]

On Thu, Jun 7, 2012 at 1:14 PM, Randy Bush  wrote:
>> so... now that this can is open, has anyone looked at:
>>   
>
> yep.  yet another bucket of identity slime wanting to resell my
> identity.

maybe? they don't seem to want to be the 'identity provider' directly
though, or rather they point out that your corporation could be your
identity provider (or anyone else you might trust) they simply sell
the enabling software/tech.

Re: LinkedIn password database compromised

[Tei]

The problem:
- Modern internet users must have lots of different login/passwords around
the internet.  Most of then in easy-to-break poorly-patched poorly-managed
servers,  like linkedin.

The solution:
-  Reduce the number of authentication.  Allow anonymous posting in more
sites.

Imagine this.   I post something on the blog  "yadaydayda". I give my email
and nothing else.   The blog software sends me a email to confirm the post.
I click on it, and the post is published.

The real problem is that nowdays everybody and his dog want a password, and
a password is expensive for the user.  The internet need more anonymous
ways to publish content.


-- 
--
ℱin del ℳensaje.

Re: LinkedIn password database compromised

[Randy Bush]

> so... now that this can is open, has anyone looked at:
>   

yep.  yet another bucket of identity slime wanting to resell my
identity.

randy

Re: LinkedIn password database compromised

[Christopher Morrow]

On Thu, Jun 7, 2012 at 1:03 PM, Randy Bush  wrote:
> hi etaoin,
>
>> I still don't want single sign on.  Not anywhere.
>
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks.  essentially it means that the 'identiry provider' owns
> your identity.  i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.

so... now that this can is open, has anyone looked at:
  

they seem to have some interesting options for better authentication.

> the 'single sign on' i encourage for the end using human beings i
> support is 1password and its ilk.  it provides the user with one sign-on
> yet strongly encourages separation of identities and strong passwords
> for sites.

the oneid people would say: "it is still a shared secret"

-chris

Re: LinkedIn password database compromised

[Randy Bush]

hi etaoin,

> I still don't want single sign on.  Not anywhere.

i believe that 'single sign on' is a bad deal and dangerous for all, not
just we geeks.  essentially it means that the 'identiry provider' owns
your identity.  i love that they call themselves 'identity providers'
when it is MY fracking identity and they are reselling it.

the 'single sign on' i encourage for the end using human beings i
support is 1password and its ilk.  it provides the user with one sign-on
yet strongly encourages separation of identities and strong passwords
for sites.

add to that, something such as ghostery for your browser, and you have a
small chance of actually preserving your identity and minimizing cross-
site tracking.

randy

Re: AAAA's for www.netflix.com

[Daniel Roesen]

On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote:
> Just to close the loop on this - UltraDNS has an issue with CNAMEs and 
> their Directional DNS service.  We (Netflix) have applied a workaround and 
> it appears stable.

Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't
improve visibility of the , but decreased it.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: LinkedIn password database compromised

[Lynda]

On 6/7/2012 8:58 AM, Jared Mauch wrote:


On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:


Imaging signing up for a site by putting in your email and pasting
your public key.



I'm imagining my mother trying this, or trying to help her change it
after the hard drive dies and the media in the safe deposit box
doesn't read anymore.


There are other issues than not being familiar with technology, and they 
specifically affect those of us who have grown older, and lost certain 
dexterity that used to be innate. There are passwords and pass phrases I 
used to have committed to muscle memory. I never even had to think about 
them. I've had to spend literally hours trying to type in a PGP pass 
phrase that used to be something I could type without thinking.


There is no one size fits all solution to this. I'm still very annoyed 
with a company that has only now moved to a password solution that 
should have been in place in 2005. I still don't want single sign on. 
Not anywhere. I've been around for a very long time, and I'm fine with 
technical complexity for me, but do not expect the standard 16 year old 
text messaging addict to be able to handle some of the solutions I've 
seen suggested, much less most people my age.


Things are so complex now that people on nanog-l forget the average 
level of expertise among their peer groups is simply not replicated in 
the outside world. Jokes about needing a teenager to reprogram your VCR 
are a thing of the past. I used to be in the business of forecasting the 
future (among other things), and any security solution that is more 
difficult than knowing not to use the same password for your bank that 
you do for Facebook is doomed to fail.


{P.S. Ditto on thanks for backup DNS.}

--
A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately
described with pictures.

RE: LinkedIn password database compromised

[Bruch, Mark]

I rarely reply to threads. However the point of interest that is missed is "Not 
supported anymore because Microsoft says so". So Microsoft starts putting out 
systems at one per year and not supporting old ones because they "Have you over 
a barrel"? 

Tell your daughter she can't get married? You haven't bought your new operating 
system this year, and "backward compatible" is a thing of the past?

Then it is $119.00 per year on top of that (maybe)? 

Let's say Microsoft promised business to the PC building companies and decides 
that an operating system per year is only supported on new equipment? The cost 
to vote could be thousands per year. Only the rich can afford to vote?

The point is that you have to be careful about where you go with technology and 
who controls it. I am sure there are people who would love to see voting as a 
"can you afford it" right.

-Original Message-
From: Aaron C. de Bruyn [mailto:aa...@heyaaron.com] 
Sent: Thursday, June 07, 2012 11:10 AM
To: Jared Mauch
Cc: Nanog
Subject: Re: LinkedIn password database compromised

On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch  wrote:
> I'm imagining my mother trying this, or trying to help her change it after 
> the hard drive dies and the media in the safe deposit box doesn't read 
> anymore.

I would think it's fairly simple.
What if she forgot her existing password?  Most sites have a 'reset password' 
link they e-mail you.
A browser extension 'helper' would simply generate a new key and let you reset 
your password.  Maybe the helper could be dumbed down enough to automatically 
handle the password reset screen and automatically POST the new key to the 
reset page.

I'm sure it could be done transparently enough that our mothers wouldn't need 
to think twice about it.

Heck--the 'helper' could probably even back up your SSH key off-site sorta like 
LastPass does.  And if your private key is actually password protected, it's 
slightly less useless if the off-site backup company were compromised.

The only downfall is how do you get access to your e-mail account?
(Google already calls my cell and/or home phone if I request access without 
using my password.)

I agree there are stumbling blocks, and it wouldn't be perfect--but it seems 
like it would be much better than the alternative we have now.
People using the same password on multiple sites, passwords written down, dumb 
website operators not salting their hashes, etc...

Also, thanks for the great secondary DNS service.  ;)

-A

Re: LinkedIn password database compromised

[Marshall Eubanks]

On Thu, Jun 7, 2012 at 11:58 AM, Jared Mauch  wrote:
>
> On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:
>
>> Imaging signing up for a site by putting in your email and pasting
>> your public key.
>>
>
> I'm imagining my mother trying this, or trying to help her change it after 
> the hard drive dies and the media in the safe deposit box doesn't read 
> anymore.

Or having to deal with family tech support, along the lines of

"You said you pasted it exactly."

"But I did. I've spent hours trying to watch that movie. I don't know
why it isn't working."

"But you {added a period at the end / didn't include the  line wrap /
added a space at the beginning / etc}"

"Oh. Does that matter"

For more joy, imagine debugging such issues over the phone. At least I
can say that my Mother (God rest her soul) would never
have indulged in such foolery. She would have just called the company
to send a technician in to send the email for her.

Regards
Marshall

Re: LinkedIn password database compromised

[Aaron C. de Bruyn]

On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch  wrote:
> I'm imagining my mother trying this, or trying to help her change it after 
> the hard drive dies and the media in the safe deposit box doesn't read 
> anymore.

I would think it's fairly simple.
What if she forgot her existing password?  Most sites have a 'reset
password' link they e-mail you.
A browser extension 'helper' would simply generate a new key and let
you reset your password.  Maybe the helper could be dumbed down enough
to automatically handle the password reset screen and automatically
POST the new key to the reset page.

I'm sure it could be done transparently enough that our mothers
wouldn't need to think twice about it.

Heck--the 'helper' could probably even back up your SSH key off-site
sorta like LastPass does.  And if your private key is actually
password protected, it's slightly less useless if the off-site backup
company were compromised.

The only downfall is how do you get access to your e-mail account?
(Google already calls my cell and/or home phone if I request access
without using my password.)

I agree there are stumbling blocks, and it wouldn't be perfect--but it
seems like it would be much better than the alternative we have now.
People using the same password on multiple sites, passwords written
down, dumb website operators not salting their hashes, etc...

Also, thanks for the great secondary DNS service.  ;)

-A

RE: IPv6 day and tunnels

[Templin, Fred L]

Here is Matt's full table and descriptive text:

"Note that there is no specific reason to require any particular
 MTU at any particular rate. As a general principle, we prefer
 declining packet times (and declining worst case jitter) as you
 go to higher rates.

  Actual  Vision  Alternate 1  Alternate 2 
  Rate  MTU TimeMTU   Time MTU   TimeMTU  Time 
  10 Mb/s  1.5kB  1200uS   
 100 Mb/s  1.5kB   120uS12kB  960uS9kB  720uS  4.3kB   433uS 
   1 Gb/s  1.5kB12uS96kB  768uS   64kB  512uS9kB72uS 
  10 Gb/s  1.5kB   1.2uS   750kB  600uS  150kB  120uS   64kB  51.2uS 
 100 Gb/s6MB  480uS  1.5MB  120uS   64kB  5.12uS 
   1 Tb/s   50MB  400uS   15MB  120uS   64kB 0.512uS 

 The above numbers are very speculative about what MTUs might
 make sense in the market. We keep updating them as we learn
 more about how MTU affects the balance between switching
 costs and end-system costs vs. end-to-end performance."

If you wish, you can also consider Alternate 3 for 9kB:
72us@1Gbps, 7.2us@10Gbps, .72us@100Gbps, .072us@1Tbps.

Fred
fred.l.temp...@boeing.com

Re: LinkedIn password database compromised

[Jared Mauch]

On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote:

> Imaging signing up for a site by putting in your email and pasting
> your public key.
> 

I'm imagining my mother trying this, or trying to help her change it after the 
hard drive dies and the media in the safe deposit box doesn't read anymore.

RE: LinkedIn password database compromised

[Matthew Huff]

True,

Back in 1998-1999 timeline, there was an ongoing project to have the US
Postal service issue X.509 certificates at a nominal fee. The fact that even
the most rural areas have access to a post office made a lot of sense. After
the 2000 election, the project was cancelled because "private business" can
handle it better.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: jeff murphy [mailto:jcmur...@jeffmurphy.org]
> Sent: Thursday, June 07, 2012 10:06 AM
> To: Nanog
> Subject: Re: LinkedIn password database compromised
> 
> 
> On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote:
> 
> > In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron
> C. de Bruyn wrote:
> >> Heck no to X.509.  We'd run into the same issue we have right now--a
> >> select group of companies charging users to prove their identity.
> >
>   ...
> > For instance, I'm not at all opposed to the idea of the government
> > having a way to issue me a signed certificate that I then use to
> > access government services, like submitting my tax return online,
> > renewing my drivers license, or maybe even e-voting.
> 
> 
> 
> All in favor of paying $119/year to vote, please raise your hands.
> 
> http://www.verisign.com/dod-interoperability/



smime.p7s
Description: S/MIME cryptographic signature

Re: LinkedIn password database compromised

[Aaron C. de Bruyn]

On Thu, Jun 7, 2012 at 6:36 AM, Peter Kristolaitis  wrote:
> On 6/7/2012 9:22 AM, James Snow wrote:
>> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
>>>
> "Imagine if the website has a lock on it, and you tell them what key you
> want to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of the
> other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"

You'd run into the same issue explaining how MD5, SHA1, salting,
etc... works to 'protect' their password.
Users don't care.
If putty were to pop up its password box when my mother signed in to
her computer and then I said something like "Don't worry, you won't
need to enter passwords while you surf the 'net now." and maybe showed
her the chrome extension icon thingy to click when she wants to paste
her 'password' (public key) into a new site, she'd be fine with it.

> The other problem with this approach is that, as bad as trusting remote
> sites to do security properly is, I'm not sure that putting a "one key to
> rule them all" on users' machines is that much better, given the average
> user's penchant for installing malware on their machine because
> "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time...

And how does our current system of usernames and passwords avoid
malware that logs keystrokes?

> I suspect we'd see a huge wave of malware whose sole purpose is to steal
> public keys (and you KNOW users won't password-protect their private keys!).
>   Plus, now you have the problem of users not being able to login to their
> favourite websites when they're using a friend's computer, internet cafe,
> etc, unless they've remembered to bring a copy of their private key with
> them.

Yep--that's the one big problem I can see with this 'solution' that I
don't have an answer for yet.
It would be difficult to get users to carry around a USB key or a
smartcard, or whatever to get them signed in while away from their
home computer.

-A

Re: LinkedIn password database compromised

[JC Dill]

On 07/06/12 6:36 AM, Peter Kristolaitis wrote:
Plus, now you have the problem of users not being able to login to 
their favourite websites when they're using a friend's computer, 
internet cafe, etc, unless they've remembered to bring a copy of their 
private key with them.


I've run into this problem with setting up accounts on aps on my 
smartphone.  A secure password that is relatively easy to type on a 
regular keyboard becomes a PITA to type on a smartphone.  There are a 
number of sites I simply don't use on my phone because the hassle of 
setting up each site's ap is greater than the benefit I get from 
accessing it via the phone.


jc

Re: LinkedIn password database compromised

[jeff murphy]

On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote:

> In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de 
> Bruyn wrote:
>> Heck no to X.509.  We'd run into the same issue we have right now--a
>> select group of companies charging users to prove their identity.
> 
...
> For instance, I'm not at all opposed to the idea of the
> government having a way to issue me a signed certificate that I
> then use to access government services, like submitting my tax
> return online, renewing my drivers license, or maybe even e-voting.



All in favor of paying $119/year to vote, please raise your hands.

http://www.verisign.com/dod-interoperability/

Re: LinkedIn password database compromised

[Leo Bicknell]

In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de 
Bruyn wrote:
> Heck no to X.509.  We'd run into the same issue we have right now--a
> select group of companies charging users to prove their identity.

Why?

A user providing the public half of a self-signed certificate is
exactly the same as the user providing the public half of a
self-generated SSH key.

The fact that you can have a trust chain may be useful in some
cases.  For instance, I'm not at all opposed to the idea of the
government having a way to issue me a signed certificate that I
then use to access government services, like submitting my tax
return online, renewing my drivers license, or maybe even e-voting.

The X.509 certificates have an added bonus that they can be used
to secure the transport layer, something that your ssh-key-for-login
proposal can't do.

This is all a UI problem.  If Windows/OSX or Safari/Firefox/Chrome
prompted users to create or import a "user certificate" when first
run, and provided a one-click way to provide it to a form when signing
up there would be a lot more incentive to use that method.  Today pretty
much the only place you see certificates for users is Enterprises with
Microsoft's certificate tools because of the UI problem.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpWPTkGZcThO.pgp
Description: PGP signature

Re: AAAA's for www.netflix.com

[Dave Temkin]

Just to close the loop on this - UltraDNS has an issue with CNAMEs and their Directional DNS service.  We 
(Netflix) have applied a workaround and it appears stable.


-Dave

On 6/6/12 8:05 AM, Frank Bulk wrote:

I started monitoring IPv6 access to www.netflix.com after seeing this
posting
(http://www.personal.psu.edu/dvm105/blogs/ipv6/2012/06/netflix-is-back.html)
and what I found, over the week, was that access was coming and going
(www.premieronline.net/~fbulk/netflix.png).  But not because of IPv6
connectivity, but because the 's were coming and going.  Netflix's DNS
TTL is pretty short.

I assume Netflix has some global DNS load balancing so my perspective may
not be complete.  Has anyone else been seeing this?

I contacted a Netflix employee (he's well known on this list) and he
responded once but I haven't heard back since Saturday.

Here's some sample queries from Saturday and today.
=
nagios:/home/fbulk# dig  www.netflix.com

;<<>>  DiG 9.7.3<<>>   www.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26825
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.netflix.com.   IN  

;; AUTHORITY SECTION:
netflix.com.150 IN  SOA dns.netflix.com.
nicadmin.netflix.com. 2012060104 900 600 1209600 1800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun  2 09:29:17 2012
;; MSG SIZE  rcvd: 82

nagios:/home/fbulk#
=

=
nagios:/home/fbulk# dig  www.netflix.com

;<<>>  DiG 9.7.3<<>>   www.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33117
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 8, ADDITIONAL: 0

;; QUESTION SECTION:
;www.netflix.com.   IN  

;; ANSWER SECTION:
www.netflix.com.132 IN  CNAME
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::3210:e195
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::3213:5282
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::3213:6340
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::3213:779a
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::1715:75cd
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::1715:eceb
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::1717:e388
dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN
 2406:da00:ff00::1717:eb58

;; AUTHORITY SECTION:
elb.amazonaws.com.  7092IN  NS  ns-916.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-941.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-927.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-925.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-934.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-935.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-944.amazonaws.com.
elb.amazonaws.com.  7092IN  NS  ns-947.amazonaws.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun  2 09:34:35 2012
;; MSG SIZE  rcvd: 504

nagios:/home/fbulk#
=

=
nagios:/home/fbulk# dig  www.netflix.com

;<<>>  DiG 9.7.3<<>>   www.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34529
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.netflix.com.   IN  

;; AUTHORITY SECTION:
netflix.com.94  IN  SOA dns.netflix.com.
nicadmin.netflix.com. 2012060107 900 600 1209600 1800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jun  6 09:00:44 2012
;; MSG SIZE  rcvd: 82

nagios:/home/fbulk#
=

Frank Bulk

Re: LinkedIn password database compromised

[Peter Kristolaitis]

On 6/7/2012 9:22 AM, James Snow wrote:

On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:

Imaging signing up for a site by putting in your email and pasting
your public key.

Yes! Yes! Yes!

I've been making this exact argument for about a year. It even retains
the same "email a link" reset mechanism when someone needs to reset
their key.

A common counter-argument is, "But ordinary Internet users won't
understand SSH keys." They don't need to! The idea is easily explained
via a lock-and-key metaphor that people already understand. The UI for
walking users through key creation is easily imagined.


-Snow


Oh yeah, I can just imagine that "lock and key" conversation now...

"Imagine if the website has a lock on it, and you tell them what key you 
want to use by giving them a copy."
"But if they have a copy of my key, couldn't they use it to open all of 
the other locks I've set up to use it?"

"(explain public key crypto)"
"(drool, distraction by the latest Facebook feature)"

The other problem with this approach is that, as bad as trusting remote 
sites to do security properly is, I'm not sure that putting a "one key 
to rule them all" on users' machines is that much better, given the 
average user's penchant for installing malware on their machine because 
"FunnyMonkeyScreensaver.exe" sounded like such a good idea at the 
time...   I suspect we'd see a huge wave of malware whose sole purpose 
is to steal public keys (and you KNOW users won't password-protect their 
private keys!).   Plus, now you have the problem of users not being able 
to login to their favourite websites when they're using a friend's 
computer, internet cafe, etc, unless they've remembered to bring a copy 
of their private key with them.


I think public key auth for websites is a great idea for geeks who 
understand the benefits, limitations and security concerns, but I have 
serious doubts that it would hold up when subjected to the "idiot test".


- Pete




smime.p7s
Description: S/MIME Cryptographic Signature

Re: LinkedIn password database compromised

[James Snow]

On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
> 
> Imaging signing up for a site by putting in your email and pasting
> your public key.

Yes! Yes! Yes!

I've been making this exact argument for about a year. It even retains
the same "email a link" reset mechanism when someone needs to reset
their key.

A common counter-argument is, "But ordinary Internet users won't
understand SSH keys." They don't need to! The idea is easily explained
via a lock-and-key metaphor that people already understand. The UI for
walking users through key creation is easily imagined.


-Snow