This is bigger than the "perpass" list.
I suggested that the surveillance/broken crypto challenge represents "damage to
the Internet". I'm not the only one thinking that way.
I'd like to share the challenge raised by Bruce Schneier in:
http://www.theguardian.com/commentisfree/2013/sep/05/gover
On Thu, 5 Sep 2013, Dean Willis wrote:
This is bigger than the "perpass" list.
I suggested that the surveillance/broken crypto challenge represents "damage to the
Internet". I'm not the only one thinking that way.
an additional call to action can be found here:
http://www.newamerica.net/pr
I'm sorry, I don't detect the emergency.
I'm not saying there's no issue or no work to do, but what's new about
any of this?
Was PRISM a surprise to anyone who knew that the Five Eyes sigint
organisations have been cooperating since about 1942 and using
intercontinental data links since 1944)? Wa
On Sep 5, 2013 5:17 PM, "Dean Willis" wrote:
>
>
> This is bigger than the "perpass" list.
>
> I suggested that the surveillance/broken crypto challenge represents
"damage to the Internet". I'm not the only one thinking that way.
>
> I'd like to share the challenge raised by Bruce Schneier in:
>
>
On Sep 5, 2013, at 8:46 PM, Lucy Lynch wrote:
>> I'd like to share the challenge raised by Bruce Schneier in:
I thought it was a great call to action. Is Bruce coming to Vancouver?
On Sep 5, 2013, at 9:36 PM, Brian E Carpenter
wrote:
> I'm sorry, I don't detect the emergency.
I think we all knew NSA was collecting the data. Why didn't we do something
about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We
certainly thought it was an emergency ba
On Thu, Sep 5, 2013 at 9:36 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> I'm sorry, I don't detect the emergency.
>
> I'm not saying there's no issue or no work to do, but what's new about
> any of this?
>
> Was PRISM a surprise to anyone who knew that the Five Eyes sigint
> organ
> From: Dean Willis
> The [IETF] .. needs dedicate its next meeting to this task. This is
> an emergency, and demands an emergency response.
The thing is that I'm not sure how much of this is the NSA 'breaking'
protocols/algorithms, and how much is finding ways past/around that secur
On 06/09/2013 15:08, Ted Lemon wrote:
> On Sep 5, 2013, at 9:36 PM, Brian E Carpenter
> wrote:
>> I'm sorry, I don't detect the emergency.
>
> I think we all knew NSA was collecting the data. Why didn't we do something
> about it sooner? Wasn't it an emergency when the PATRIOT act was passe
On 9/5/2013 8:08 PM, Ted Lemon wrote:
they convinced us we'd won
We've done quite a sales job on ourselves, also.
Remember the IAB tech plenary that declared protocols dead, because the
client is downloaded from the server? Think about that, in the light of
recent revelations about compro
On 06/09/2013 15:11, Phillip Hallam-Baker wrote:
...
> S/MIME is almost what we need to secure email. What is missing is an
> effective key discovery scheme. We could add that and add Ben Laurie's
> Certificate Transparency and have a pretty good start on a PRISM Proof
> email scheme.
OK, that's a
On 9/5/13 7:19 PM, Brian E Carpenter wrote:
> I'm not talking about what implementors and operators and users
> should be doing; still less about what legislators should or
> shouldn't be doing. I care about all those things, but the question
> here is what standards or informational outputs from t
On Fri, Sep 6, 2013 at 8:41 AM, Phillip Hallam-Baker wrote:
>
> On Thu, Sep 5, 2013 at 9:36 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> I'm sorry, I don't detect the emergency.
>>
>> I'm not saying there's no issue or no work to do, but what's new about
>> any of this?
>
>
>
On Fri, Sep 06, 2013 at 03:28:28PM +1200, Brian E Carpenter wrote:
>
> OK, that's actionable in the IETF, so can we see the I-D before
> the cutoff?
Why is that discussion of this nailed to the cycle of IETF meetings?
A
--
Andrew Sullivan
a...@anvilwalrusden.com
On Fri, Sep 6, 2013 at 9:02 AM, Vinayak Hegde wrote:
> On Fri, Sep 6, 2013 at 8:41 AM, Phillip Hallam-Baker wrote:
>
>>
>> On Thu, Sep 5, 2013 at 9:36 PM, Brian E Carpenter <
>> brian.e.carpen...@gmail.com> wrote:
>>
>>> I'm sorry, I don't detect the emergency.
>>>
>>> I'm not saying there's no i
> From: Phillip Hallam-Baker
> S/MIME is almost what we need to secure email.
If by "secure email" you mean 'render email impervious to being looked at
while on the wire', perhaps. If, however, you mean 'render it secure from
ever being looked at by anyone else', no way.
Even if it's st
On Thu, Sep 5, 2013 at 11:28 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 06/09/2013 15:11, Phillip Hallam-Baker wrote:
> ...
> > S/MIME is almost what we need to secure email. What is missing is an
> > effective key discovery scheme. We could add that and add Ben Laurie's
> >
On Thu, Sep 5, 2013 at 11:32 PM, Andrew Sullivan wrote:
> On Fri, Sep 06, 2013 at 03:28:28PM +1200, Brian E Carpenter wrote:
> >
> > OK, that's actionable in the IETF, so can we see the I-D before
> > the cutoff?
>
> Why is that discussion of this nailed to the cycle of IETF meetings?
It is not.
On 6 sep 2013, at 05:39, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
>> From: Phillip Hallam-Baker
>
>> S/MIME is almost what we need to secure email.
>
> If by "secure email" you mean 'render email impervious to being looked at
> while on the wire', perhaps. If, however, you mean 'render it
> This assumes, of course, that current crypto technology
> (ciphers, anyway) is sufficient, which Schneier seems to
> think is the case.
side discussion wonders whether bruce may be a bit on the
pollyanna side on this aspect.
randy
On 9/5/13 8:59 PM, Randy Bush wrote:
> side discussion wonders whether bruce may be a bit on the
> pollyanna side on this aspect.
That's a really interesting question, and I have no idea what
the answer is. One reason it's interesting is that until
this all broke there was a reasonable assumption
I think we should seize this opportunity to take a hard look at what we can do
better. Yes, it is completely correct that this is only partially a technical
problem, and that there is a lot of technology that, if used, would help. And
that technical issues outside IETF space, like endpoint secur
On 9/6/13 5:11 AM, Phillip Hallam-Baker wrote:
> S/MIME is almost what we need to secure email. What is missing is an
> effective key discovery scheme. We could add that and add Ben Laurie's
> Certificate Transparency and have a pretty good start on a PRISM Proof
> email scheme.
Not when the key
> And that no amount of communication security helps you if you do not the guy
> at the other end.
Do not *trust* the guy at the other end. Typos, sigh…
At 20:32 05-09-2013, Vinayak Hegde wrote:
While it is nice to do a dedication of this meeting to the SA
surveillance, I do not see us solving any issue here. It is merely a
"feel-good" measure without real impact.
:-)
Second, technology can never fix what is essentially a political
problem.
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving
the Internet from the NSA Date: Fri, Sep 06, 2013 at 09:04:41AM +0300 Quoting
Jari Arkko (jari.ar...@piuha.net):
> I think we should seize this opportunity to take a hard look at what we can
> do better.
Bruce might not know that we have already various activities ongoing. I
just recently produced a short writeup about the efforts related to this
topic ongoing at the last IETF meeting on my blog:
http://www.tschofenig.priv.at/wp/?p=993
Ciao
Hannes
On 06.09.2013 03:17, Dean Willis wrote:
This
On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
Tell me what the IETF could be doing that it isn't already doing.
I'm not talking about what implementors and operators and users should
be doing; still less about what legislators should or shouldn't be
doing. I care about all those things, but t
On Fri, Sep 6, 2013 at 12:16 PM, SM wrote:
> In a Last Call comment a few months ago it was mentioned that a
> specification takes the stance that security is an optional feature. I
> once watched a Security Area Director spend thirty minutes trying to
> explain to a working group that security
On 06.09.2013 04:36, Brian E Carpenter wrote:
I'm not saying there's no issue or no work to do, but what's new about
any of this?
Still at the end of last year I remember conversations in working groups
that questions why we need TLS security for protocols like SCIM (a
protocol that shuffles
On 06/09/2013 04:19, Brian E Carpenter wrote:
On 06/09/2013 15:08, Ted Lemon wrote:
On Sep 5, 2013, at 9:36 PM, Brian E Carpenter
wrote:
I'm sorry, I don't detect the emergency.
I think we all knew NSA was collecting the data. Why didn't we do something
about it sooner? Wasn't it an eme
Summarising a *lot* :-)
On 09/06/2013 11:30 AM, Stewart Bryant wrote:
>
> There is a whole bunch of stuff we can do
I fully agree. Some more detail on one of those...
We setup the perpass list [1] as a venue for triaging
specific proposals in this space. A few weeks in, we
have one I-D [2] (ve
On 06.09.2013 13:30, Stewart Bryant wrote:
Tell me what the IETF could be doing that it isn't already doing.
It really depends where you see the boundaries of the IETF.
For some the IETF only produces documents and that's it. Clearly, we
have a lot of specification work ongoing in different ar
IMHO. There is no amount of engineering that can fix stupid people doing
stupid things... on both sides of the stupid line.
-J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/6/13 1:47 AM, Adam Novak wrote:
> On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
>> Tell me what the IETF could be doing that it isn't already
>> doing.
>>
>> I'm not talking about what implementors and operators and users
>> should be doing; s
On Fri, Sep 6, 2013 at 7:07 AM, Hannes Tschofenig wrote:
> On 06.09.2013 13:30, Stewart Bryant wrote:
>
>> Tell me what the IETF could be doing that it isn't already doing.
>>
> It really depends where you see the boundaries of the IETF.
>
> For some the IETF only produces documents and that's it
On 06/09/13 14:07, Hannes Tschofenig wrote:
While we are able to fill gaps in security protocols fairly quickly we
don't always seem to make the right choices because the interests of
various participants are not necessarily aligned.
So, what if an NSA guys comes in and proposes backdoor to be
On 9/6/13 3:04 PM, Martin Sustrik wrote:
> So, what if an NSA guys comes in and proposes backdoor to be added to
> a protocol? Is it even a valid interest? Does IETF as an organisation
> have anything to say about that or does it remain strictly neutral?
>
It's happened before and we as a communit
* Brian E Carpenter wrote:
>Tell me what the IETF could be doing that it isn't already doing.
The United States justify these programs saying they are primarily used
to support their various current and future war efforts. Not meeting at
any level in countries currently at war might be a sound IET
> From: Martin Millnert
> Bruce was ... suggesting that encrypting everything on the wire makes
> both metadata and payload collection from wires less valuable. Here
> comes the key point: Encrypting everything on the wire raises the cost
> for untargeted mass surveillance sig
+1. I'd +10 if I could :-)
> One thing that would be helpful is to encourage the use of
> Diffie-Hellman everywhere. Even without certificates that can be
> trusted, we can eliminate the ability of casual, dragnet-style
> surveillance. Sure, an attacker can still do a MITM attack. But (a)
> peo
One thing that would be helpful is to encourage the use of
Diffie-Hellman everywhere. Even without certificates that can be
trusted, we can eliminate the ability of casual, dragnet-style
surveillance. Sure, an attacker can still do a MITM attack. But (a)
people who are more clueful can do certif
> From: Scott Brim
> I wouldn't focus on government surveillance per se. The IETF should
> consider that breaking privacy is much easier than it used to be ...
> right now the Internet's weakness in privacy is far from "better". The
> mandatory security considerations section
On Sep 6, 2013, at 2:46 AM, SM wrote:
> At 20:08 05-09-2013, Ted Lemon wrote:
>> I think we all knew NSA was collecting the data. Why didn't we do
>> something about it sooner? Wasn't it an emergency when the PATRIOT act was
>> passed? We certainly thought it was an emergency back in the d
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
> We currently do not have a concise catalog the basic 'privacy'
> threats and their typical mitigations, appropriate for concern with
> IETF protocols.
What about RFC 6973?
On Fri, Sep 6, 2013 at 10:55 AM, Dave Crocker wrote:
> In other words, the IETF needs to assume that we don't know what will work
> for end users and we need to therefore focus more on processing by end
> /systems/ rather than end /users/.
... and do not close off any options because we assume pe
On 9/6/2013 5:51 AM, Jorge Amodio wrote:
IMHO. There is no amount of engineering that can fix stupid people doing
stupid things... on both sides of the stupid line.
Correct. Within the IETF, the most serious example of stupidity is any
line of analysis that considers end-users to be stupid
> From: Spencer Dawkins
> I have to wonder whether weakening crypto systems to allow pervasive
> passive monitoring by "national agencies" would weaken them enough for
> technologically savvy corporations to monitor their competitors, for
> instance.
More importantly, if cryp
On Sep 6, 2013, at 3:25 AM, Måns Nilsson wrote:
> I do think that more distributed technoligies like DANE play an important
> rôle here.
Right, because there's no way the NSA could ever pwn the DNS root key.
What we should probably be thinking about here is:
- Mitigating single points of fail
There are a lot more threats to privacy than just the NSA
We currently do not have a concise catalog the basic 'privacy' threats
and their typical mitigations, appropriate for concern with IETF
protocols. In effect, every new protocol effort must start with a blank
sheet, and invent its ow
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations, appropriate for concern with
IETF protocols.
Hi Vinayak,
At 01:13 06-09-2013, Vinayak Hegde wrote:
It is tragic if the community does understand strong encryption is
essential in many cases (with the caveat that it is not a panacea
for all security breaches) As for raising issues at the last-call.
Why not ? The last-call is no different t
Brian E Carpenter wrote:
>> I think we all knew NSA was collecting the data. Why didn't we do
>> something about it sooner? Wasn't it an emergency when the PATRIOT
>> act was passed? We certainly thought it was an emergency back in the
>> days of Skipjack, but then they convinc
You're right that a flat mesh is not the best topology for
long-distance communication, especially with current routing
protocols, which require things like global lists of all routeable
prefixes.
On the protocol front, I suggest that the IETF develop routing
protocols that can work well in a flat
On 9/6/13, Brian E Carpenter wrote:
>
> Tell me what the IETF could be doing that it isn't already doing.
>
> I'm not talking about what implementors and operators and users should
> be doing; still less about what legislators should or shouldn't be
> doing. I care about all those things, but the
On 06.09.2013 18:53, SM wrote:
At 06:04 06-09-2013, Martin Sustrik wrote:
So, what if an NSA guys comes in and proposes backdoor to be added to
a protocol? Is it even a valid interest? Does IETF as an organisation
have anything to say about that or does it remain strictly neutral?
Would anyone
Dave,
On 06.09.2013 18:58, Dave Crocker wrote:
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations,
On Sep 6, 2013, at 8:07 AM, Eliot Lear wrote:
>
> On 9/6/13 3:04 PM, Martin Sustrik wrote:
>> So, what if an NSA guys comes in and proposes backdoor to be added to
>> a protocol? Is it even a valid interest? Does IETF as an organisation
>> have anything to say about that or does it remain stric
On 9/6/2013 10:46 AM, Ted Lemon wrote:
The threat model isn't really the NSA per se—if they really want to
bug you, they will, and you can't stop them, and that's not a
uniformly bad thing. The problem is the breathtakingly irresponsible
weakening of crypto systems that has been alleged here, a
On 9/6/13 4:47 AM, Adam Novak wrote:
> On 09/05/2013 08:19 PM, Brian E Carpenter wrote:
>> Tell me what the IETF could be doing that it isn't already doing.
>>
>> I'm not talking about what implementors and operators and users should
>> be doing; still less about what legislators should or sho
On Sep 6, 2013, at 9:55 AM, Dave Crocker wrote:
>
> In other words, the IETF needs to assume that we don't know what will work
> for end users and we need to therefore focus more on processing by end
> /systems/ rather than end /users/.
But we are also end users. I recall being laughed at 6 o
On 9/6/2013 11:42 AM, Dean Willis wrote:
On Sep 6, 2013, at 9:55 AM, Dave Crocker wrote:
In other words, the IETF needs to assume that we don't know what
will work for end users and we need to therefore focus more on
processing by end /systems/ rather than end /users/.
But we are also end use
On Sep 6, 2013, at 2:31 PM, Dean Willis wrote:
> What if they didn't say they were NSA guys, but just discretely worked a
> weakness into a protocol? What if they were a trusted senior member of the
> community?
If we have trusted senior members making false statements that can be shown to
be
On 09/06/2013 11:46 AM, Ted Lemon wrote:
> The threat model isn't really the NSA per se—if they really want to bug you,
> they will, and you can't stop them, and that's not a uniformly bad thing.
I disagree, or at least, I think that your statement conflates two
different threat models.
One kin
On 9/6/2013 11:38 AM, Noel Chiappa wrote:
> From: Spencer Dawkins
> I have to wonder whether weakening crypto systems to allow pervasive
> passive monitoring by "national agencies" would weaken them enough for
> technologically savvy corporations to monitor their competitors
On Sep 6, 2013, at 2:06 PM, Måns Nilsson wrote:
>> Right, because there's no way the NSA could ever pwn the DNS root key.
> It is probably easier for NSA or similar agencies in other countries
> to coerce X.509 root CA providers that operate on a competetive market
> than fooling the entire intern
+Bruce Schneier (at least the email address published in his latest I-D), since
he should be at least aware of the discussion his callout has generated.
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Ted Lemon
>
> On Sep 5, 2013, at 8:46 P
Hi Dean,
At 11:31 06-09-2013, Dean Willis wrote:
What if they didn't say they were NSA guys, but just discretely
worked a weakness into a protocol? What if they were a trusted
senior member of the community?
Trust does not work well without accountability. There is less to
worry about if you
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving
the Internet from the NSA Date: Fri, Sep 06, 2013 at 11:46:17AM -0400 Quoting
Ted Lemon (ted.le...@nominum.com):
> On Sep 6, 2013, at 3:25 AM, Måns Nilsson wrote:
> > I do think that more distributed tec
How about a BCP saying conforming implementations of a wide-variety of
security-area RFCs MUST be open-source?
*ducks*
On Fri, Sep 6, 2013 at 2:34 PM, David Conrad wrote:
> On Sep 6, 2013, at 2:06 PM, Måns Nilsson
> wrote:
> >> Right, because there's no way the NSA could ever pwn the DNS root
On Sep 6, 2013, at 6:02 PM, Tim Bray wrote:
> How about a BCP saying conforming implementations of a wide-variety of
> security-area RFCs MUST be open-source?
So clearly we should do all our crypto on devices built out of 7400-series
logic. Hm, where has my old wire-wrap tool gone?
Hi Tim,
At 15:02 06-09-2013, Tim Bray wrote:
How about a BCP saying conforming implementations of a wide-variety
of security-area RFCs MUST be open-source?
A BCP is not needed to do that. It is already doable "but we [1]
know that you [2] are not going to do it".
Speaking of open source,
h
On 9/6/2013 4:19 PM, Scott Brim wrote:
On Sep 6, 2013 3:34 PM, "Dave Crocker" mailto:d...@dcrocker.net>> wrote:
> To what end? Their poor uptake clearly demonstrates some basic
usability deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as we've seen in other cases, peop
On Fri, 6 Sep 2013, Ted Lemon wrote:
> On Sep 6, 2013, at 6:02 PM, Tim Bray wrote:
> > How about a BCP saying conforming implementations of a wide-variety of
> > security-area RFCs MUST be open-source?
>
> So clearly we should do all our crypto on devices built out of 7400-series
> logic.
On Sep 6, 2013 3:34 PM, "Dave Crocker" wrote:
> To what end? Their poor uptake clearly demonstrates some basic usability
deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as we've seen in other cases, people just don't see potential
benefits large enough to motivate them.
On 7 sep 2013, at 00:02, Tim Bray wrote:
> How about a BCP saying conforming implementations of a wide-variety of
> security-area RFCs MUST be open-source?
>
> *ducks*
Well, there is something in there that makes sense.
We do have a program in the world called Common Criteria. That certificat
And who certify such agencies ?
-J
On Sat, Sep 7, 2013 at 1:24 AM, Patrik Fältström wrote:
>
>
> We do have a program in the world called Common Criteria. That
> certification program includes CCRA (CC Recognition Agreement) that implies
> that countries that run certification agencies agree th
On 7 sep 2013, at 14:33, Jorge Amodio wrote:
> And who certify such agencies ?
Today the governments, and by mutual cooperation.
That said, I think we need a generic way to have oversight over _any_ process.
Including oversight where the review is done under NDA.
In many countries that kind o
On Fri, Sep 6, 2013 at 6:02 PM, Tim Bray wrote:
> How about a BCP saying conforming implementations of a wide-variety of
> security-area RFCs MUST be open-source?
>
> *ducks*
>
And the user MUST compile them themselves from the sources?
Nobody runs open source, (unless its an interpreted langua
> On Fri, Sep 6, 2013 at 6:02 PM, Tim Bray wrote:
> > How about a BCP saying conforming implementations of a wide-variety of
> > security-area RFCs MUST be open-source?
> >
> > *ducks*
> >
> And the user MUST compile them themselves from the sources?
> Nobody runs open source, (unless its an in
On Sep 7, 2013, at 9:39 AM, Phillip Hallam-Baker wrote:
> Nor does being open source provide any additional security, only review
> provides security and it is hard enough getting people to review other
> people's code when you pay them to do that. Expecting people to spend their
> time reviewi
http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html
That's a pretty damning indictment of the development of IPSec from John
Gilmore.
Lloyd Wood
http://sat-net.com/L.Wood
...@surrey.ac.uk]
Sent: 08 September 2013 22:32
Cc: ietf@ietf.org
Subject: RE: Bruce Schneier's Proposal to dedicate November meeting to saving
the Internet from the NSA
http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html
That's a pretty damning indictment of the deve
So, has Bruce Schneier actually been invited to speak at the Technical Plenary
(or elsewhere) during the Vancouver IETF? I recall him giving an informative
talk at least one previous Tech Plenary, and in light of his 'proposal', if
would be interesting to hear what he believes to be broken, and
We're talking.
Eliot
On 9/9/13 10:20 AM, Ross Finlayson wrote:
> So, has Bruce Schneier actually been invited to speak at the Technical
> Plenary (or elsewhere) during the Vancouver IETF? I recall him giving an
> informative talk at least one previous Tech Plenary, and in light of his
> 'pro
On 9/5/13 8:28 PM, Brian E Carpenter wrote:
What we lack is not the technology, it is demand for deployment.
Exactly, and that is not actionable in the IETF.
Brian,
Some years back when we saw the lack of IPv6 deployment we started with
some IPv4-free plenary time slots - eating our own do
On 09/09/13 09:29, Eliot Lear wrote:
> We're talking.
>
> Eliot
>
>
> On 9/9/13 10:20 AM, Ross Finlayson wrote:
>> So, has Bruce Schneier actually been invited to speak at the Technical
>> Plenary (or elsewhere) during the Vancouver IETF? I recall him giving an
>> informative talk at least one p
On Sun, Sep 15, 2013 at 9:10 AM, Tobias Gondrom
wrote:
> On 09/09/13 09:29, Eliot Lear wrote:
>
> We're talking.
>
> Eliot
>
>
> On 9/9/13 10:20 AM, Ross Finlayson wrote:
>
> So, has Bruce Schneier actually been invited to speak at the Technical
> Plenary (or elsewhere) during the Vancouver IET
On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>
> One way to frustrate this sort of dragnet surveillance would be to reduce
> centralization in the Internet's architecture. Right now, the way the
> Internet works in practice for private individuals, all your traffic goes up
> one pipe to your
On 6 Sep 2013, at 21:32, Roger Jørgensen wrote:
> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>> The IETF focused on developing protocols (and reserving the necessary
>> network numbers) to facilitate direct network peering between private
>> individuals, it could make it much more expen
On 07/09/2013 08:55, Tim Chown wrote:
> On 6 Sep 2013, at 21:32, Roger Jørgensen wrote:
>
>> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
>
>
>>> The IETF focused on developing protocols (and reserving the necessary
>>> network numbers) to facilitate direct network peering between private
hum…
i did work on a DNS architecture that can be fully disconnected from
the "Internet" and still work with nodes within the visible topology.
Needs serious rework of DNSSEC and has some assumptions about topology
discovery - but it might be a basis for starting some discussio
On Sep 6, 2013 4:33 PM, "Roger Jørgensen" wrote:
>
> On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak wrote:
> >
> > One way to frustrate this sort of dragnet surveillance would be to
reduce
> > centralization in the Internet's architecture. Right now, the way the
> > Internet works in practice for pri
> From: Scott Brim
> LISP does nothing for decentralization. Traffic still flows
> hierarchically
Umm, no. In fact, one of LISP's architectural scaling issues is that it's
non-hierarchical, so xTRs have neighbour fanouts that are much larger than
typical packet switches. In basic uni
On Sep 6, 2013 10:06 PM, "Noel Chiappa" wrote:
>
> > From: Scott Brim
>
> > LISP does nothing for decentralization. Traffic still flows
> > hierarchically
>
> Umm, no. In fact, one of LISP's architectural scaling issues is that it's
> non-hierarchical, so xTRs have neighbour fanouts t
> From: Scott Brim
> The encapsulation is not much of an obstacle to packet examination.
There was actually a proposal a couple of weeks back in the WG to encrypt all
traffic on the inter-xTR stage.
The win in doing it in the xTRs, of course, is that you don't have to go
change all the
On 7 Sep 2013, at 04:05, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
>> From: Scott Brim
>
>> The encapsulation is not much of an obstacle to packet examination.
>
> There was actually a proposal a couple of weeks back in the WG to encrypt all
> traffic on the inter-xTR stage.
>
> The win i
On Sat, Sep 7, 2013 at 5:05 AM, Noel Chiappa wrote:
> > From: Scott Brim
>
> > The encapsulation is not much of an obstacle to packet examination.
>
> There was actually a proposal a couple of weeks back in the WG to encrypt all
> traffic on the inter-xTR stage.
>
> The win in doing it in
> From: =?ISO-8859-1?Q?Roger_J=F8rgensen?=
> The userbase and deployment are relative small atm so it's doable to
> get fast deployment to.
Alas, now that I think about the practicalities I don't think the average
router has enough spare computing power to completely encrypt all
On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa wrote:
> > From: =?ISO-8859-1?Q?Roger_J=F8rgensen?=
>
> > The userbase and deployment are relative small atm so it's doable to
> > get fast deployment to.
>
> Alas, now that I think about the practicalities I don't think the average
> r
1 - 100 of 103 matches
Mail list logo
