> Head on over to the Wikipedia page for SSL/TLS and then decide if you
> want rc4 to be your preference when trying to defend against a
> adversary with the resources of a nation-state.
i got hit with the clue bat on this one.
we have kinda settled on allowing rc4 for smtp as the least preferred
In message <527459c4.5000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
>
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.
> >>>
> >>> No it isn't. It requires a hu
On Fri, Nov 1, 2013 at 9:19 PM, Alex Rubenstein wrote:
> > a typical example will be the guy who run the dslam and the guy who run
> the
> > bras belong to two different companies in market which mandate open
> > access.
> ... which is very, very common.
>
It's also a troublesome situation for t
Money. The better the encryption the more it costs to crack. With forward
security you can even protect against your private key leaking.
In short, you can raise the stakes and make it economically unfeasible for
even the NSA.
John
John Souvestre - New Orleans LA - (504) 454-0899
-Or
On Nov 1, 2013, at 7:06 PM, Harry Hoffman wrote:
> That's with a recommendation of using RC4.
it’s also with 1024 bit keys in the key exchange.
> Head on over to the Wikipedia page for SSL/TLS and then decide if you want
> rc4 to be your preference when trying to defend against a adversary wi
Big Brother is always watching and Big Brother has way more resources than
network-operators in this list!
(good discussion all the same)
a) politics is the last-resort for scoundrels
b) power corrupts and absolute-power(FBI, CIA, NSA, DHS..etc,)
corrupts-absolutely.
I speak from this-side-of-t
On Nov 1, 2013, at 7:18 PM, Mike Lyon wrote:
> So even if Goog or Yahoo encrypt their data between DCs, what stops
> the NSA from decrypting that data? Or would it be done simply to make
> their lives a bit more of a PiTA to get the data they want?
Markhov chain text generators are cheap. Rath
So the latter, PITA, reason then...
-Mike
> On Nov 1, 2013, at 19:32, Harry Hoffman wrote:
>
> So, I'm not sure if I'm being too simple-minded in my response. Please let me
> know if I am.
> The purpose of encrypting data is so others can't read your secrets.
> If you use a simple substitutio
So, I'm not sure if I'm being too simple-minded in my response. Please let me
know if I am.
The purpose of encrypting data is so others can't read your secrets.
If you use a simple substitution cipher it's pretty easy to derive the set of
substitution rules used.
Stronger encryption algorithms em
George Herbert wrote:
> Anyone familiar with secure organizations will realize this as the
> internal witch hunt problem.
No hunting necessary to fire those agents who are hired at the
request of NSA/CIA.
It is also reasonable to fire those who are hired by the agents,
recursively.
> we cannot assume that the connection between isp and cpe is a single entity.
>
> a typical example will be the guy who run the dslam and the guy who run the
> bras belong to two different companies in market which mandate open
> access.
... which is very, very common.
So even if Goog or Yahoo encrypt their data between DCs, what stops
the NSA from decrypting that data? Or would it be done simply to make
their lives a bit more of a PiTA to get the data they want?
-Mike
> On Nov 1, 2013, at 19:08, Harry Hoffman wrote:
>
> That's with a recommendation of using
(2013/11/02 10:48), Alex Rubenstein wrote:
Not necessarily. When the CPE is configured through DHCP (or PPP?),
the ISP can send the secret.
>>>
>>> Which can be seen, in many cases, by other parties
>>
>> Who can see the packets sent from the local ISP to the CPE directly
>> connected to
we cannot assume that the connection between isp and cpe is a single entity.
a typical example will be the guy who run the dslam and the guy who run the
bras belong to two different companies in market which mandate open access.
Alex Rubenstein wrote:
>> >> Not necessarily. When the CPE is co
That's with a recommendation of using RC4.
Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4
to be your preference when trying to defend against a adversary with the
resources of a nation-state.
Cheers,
Harry
Niels Bakker wrote:
>* mi...@stillhq.com (Michael Still
> >> Not necessarily. When the CPE is configured through DHCP (or PPP?),
> >> the ISP can send the secret.
> >
> > Which can be seen, in many cases, by other parties
>
> Who can see the packets sent from the local ISP to the CPE directly
> connected to the ISP?
The NSA, FBI, CIA, DHS. Or, the ISP
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
>>>
>>> No it isn't. It requires a human to transfer the secret to the CPE
>>> device or to register the secret with the ISP.
>>
>>
In message <20131102002035.963ba96d...@rock.dv.isc.org>, Mark Andrews writes:
>
> In message <52743027.7050...@necom830.hpcl.titech.ac.jp>, Masataka Ohta write
> s:
> > Mark Andrews wrote:
> >
> > >> It is a lot simpler and a lot more practical just to
> > >> use shared secret between a CPE and
In message <52743027.7050...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
>
> >> It is a lot simpler and a lot more practical just to
> >> use shared secret between a CPE and a ISP's name server
> >> for TSIG generation.
> >
> > No it isn't. It requires a human to tr
> And zero documented proof. I'll just go ahead and put my tinfoil hat on
> for the remainder of this thread.
http://www.antipope.org/charlie/blog-static/2013/10/spook-century.html
--
According to Snowden, there are government agents at key
positions for managing security.
-
And zero documented proof. I'll just go ahead and put my tinfoil hat on
for the remainder of this thread.
On Fri, Nov 1, 2013 at 6:37 PM, Randy Bush wr
On Fri, Nov 1, 2013 at 4:37 PM, Randy Bush wrote:
> > Anyone familiar with secure organizations
>
> there are such things?
>
> we should be more cautious with absolutes, usually :)
>
Nothing is absolute, but there are certainly "white" organizations which
have no attempt to be secure, and much
> Anyone familiar with secure organizations
there are such things?
we should be more cautious with absolutes, usually :)
On Fri, Nov 1, 2013 at 4:01 PM, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Anthony Junk wrote:
>
> > It seems as if both Yahoo and Google assumed that since they were
> > private circuits that they didn't have to encrypt.
>
> According to Snowden, there are government agents at key
Anthony Junk wrote:
> It seems as if both Yahoo and Google assumed that since they were
> private circuits that they didn't have to encrypt.
According to Snowden, there are government agents at key
positions for managing security.
When they declare the private circuits are secure, no one
else in
Mark Andrews wrote:
>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
>
> No it isn't. It requires a human to transfer the secret to the CPE
> device or to register the secret with the ISP.
Not necessarily.
On Fri, Nov 1, 2013 at 3:26 PM, Niels Bakker wrote:
> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>
> Its about the CPU cost of the crypto. I was once told the number of CPUs
>> required to do SSL on web search (which I have now forgotten) and it was a
>> bigger number than
* mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
Its about the CPU cost of the crypto. I was once told the number of
CPUs required to do SSL on web search (which I have now forgotten)
and it was a bigger number than you'd expect -- certainly hundreds.
False: https://www.imperi
valdis.kletni...@vt.edu wrote:
>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
>
> Hmm.. Shared secret between a CPE you don't necessarily control
> and your own DNS server?
Of course. That is the very ba
BGP Update Report
Interval: 24-Oct-13 -to- 31-Oct-13 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS30693 118832 4.7% 242.0 --
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
2 -
This report has been generated at Fri Nov 1 21:13:38 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
In message <5273525c.5060...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
>
> > That said it is possible to completely automate the secure assignment
> > of PTR records. It is also possible to completely automate the
> > secure delegation of the reverse name space. S
Sent you an email off list.
Ken-
On Nov 1, 2013, at 12:21 PM, Joseph Jackson wrote:
> Anyone from Integra Telecom who knows their BGP routing on list? I
> have an open ticket but can't get past the noc techs and the issue is
> a weird one.
>
> Thanks!
>
Anyone from Integra Telecom who knows their BGP routing on list? I
have an open ticket but can't get past the noc techs and the issue is
a weird one.
Thanks!
On 11/1/13, 1:08 PM, "Gary Buhrmaster" wrote:
>On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk
>wrote:
>...
>> It seems as if both Yahoo and Google assumed that since they were
>>private
>> circuits that they didn't have to encrypt.
>
>I actually cannot see them assuming that. Google
>and Yahoo e
On Sat, November 2, 2013 6:44 am, David Miller wrote:
> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
>> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk
>> wrote:
>> ...
>>> It seems as if both Yahoo and Google assumed that since they were
>>> private
>>> circuits that they didn't have to encrypt.
>
> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
[...]
>
> Given what we now know about the breadth of the NSA operations, and the
> likelihood that this is still only the tip of the iceberg - would anyone
> still point to NSA guidance on avoiding monitoring with any sort of
> confidence?
>
> The
--- morrowc.li...@gmail.com wrote:
From: Christopher Morrow
One good reason to not do link encryption is: "the problem is that
whackadoodle box you put outside the router!" :( most often those
boxes can't do light-level monitoring, loopbacks, etc... all the stuff
your NOC wants to do when 'link
On Fri, Nov 1, 2013 at 1:06 PM, Jan Schaumann wrote:
> Christopher Morrow wrote:
>
>> One might look at MS's documentation about deploying end-to-end ipsec
>> in their enterprise for one example of peer-to-peer ubiquitous ipsec.
>
> This is interesting and kind of what I'm looking for. Do you ha
I still have some one time pads if you are good writing fast ...
-J
On Fri, Nov 1, 2013 at 11:26 AM, Randy Bush wrote:
> > For encryption of traffic between datacenters;There should be very
> > little session setup and teardown (very few public key operations);
> > almost all the crypto l
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to bgp-st...@lists.ap
On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk wrote:
> ...
>> It seems as if both Yahoo and Google assumed that since they were private
>> circuits that they didn't have to encrypt.
>
> I actually cannot see them assuming that. Google
> and Yahoo e
On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk wrote:
...
> It seems as if both Yahoo and Google assumed that since they were private
> circuits that they didn't have to encrypt.
I actually cannot see them assuming that. Google
and Yahoo engineers are smart, and taping fibres
has been well known f
Christopher Morrow wrote:
> One might look at MS's documentation about deploying end-to-end ipsec
> in their enterprise for one example of peer-to-peer ubiquitous ipsec.
This is interesting and kind of what I'm looking for. Do you have a
pointer to this documentation?
My apologies for not hav
On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta
wrote:
> Mark Andrews wrote:
>> That said it is possible to completely automate the secure assignment
>> of PTR records. It is also possible to completely automate the
>> secure delegation of the reverse name space. See
>> http://tools.ietf.org/html/
> For encryption of traffic between datacenters;There should be very
> little session setup and teardown (very few public key operations);
> almost all the crypto load would be symmetric cryptography.
trivial at 9600 baud between google datacenters
>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884
> They must be hiding their content, for fear that flaws be pointed
> out.
it's the ieee. what they're hiding is a last century business model.
randy
Hey expanoit,
There was a small part that jumped out at me when I read the article
earlier:
"In recent years, both of them are said to have bought
or leased thousands of miles of fiber-optic cables for their own exclusive
use. They had reason to think, insiders said, that their private, internal
On Fri, Nov 1, 2013 at 10:30 AM, David Barak wrote:
> Hi Jan,
>
> Please define "large scale". Is that by number of endpoints, throughput, or
> some other metric? How big is big?
>
it's fair to believe that there are 'lots' of ipsec deployments where
there are ~1000 or so endpoints (network en
Hi Jan,
Please define "large scale". Is that by number of endpoints,
throughput, or some other metric? How big is big?
David Barak
Can you give us an idea of “large scale” in your mind? Also, site to site
deployments or remote access or both?
Paul
On 11/1/2013, 9:38 AM, "Jan Schaumann" wrote:
>Hello,
>
>Who here on this list has deployed IPSec or other comparable lower layer
>encryption in a large scale environment, or a
On Fri, 01 Nov 2013 16:03:56 +0900, Masataka Ohta said:
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.
Hmm.. Shared secret between a CPE you don't necessarily control
and your own DNS server? This *will* get
Hello,
Who here on this list has deployed IPSec or other comparable lower layer
encryption in a large scale environment, or attempted to do so?
I've repeatedly heard claims that doing so is not feasible (either
operationally or financially), but I have not seen any specific studies,
reports, numb
Until you've heard an ex-NSA guy explain to you how this is done, with a
device the size of a brief-case, it can seem a little unbelievable. I had
that conversation in the late '90s.
-Original Message-
From: Matthew Petach [mailto:mpet...@netflight.com]
Sent: Thursday, October 31, 2013 8
On Thu, Oct 31, 2013 at 11:26 PM, Michael Still wrote:
> [snip]
>
> Its about the CPU cost of the crypto. I was once told the number of
> CPUs required to do SSL on web search (which I have now forgotten) and
> it was a bigger number than you'd expect -- certainly hundreds.
>
So, crypto costs m
Mark Andrews wrote:
> That said it is possible to completely automate the secure assignment
> of PTR records. It is also possible to completely automate the
> secure delegation of the reverse name space. See
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It is a lot simpler and
56 matches
Mail list logo
