Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[cb.list6]

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:
>
>
http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying
>
>
> To quote:
>
> ---
> We need to know how exactly how the NSA and other agencies are subverting
routers, switches, the internet backbone, encryption technologies and cloud
systems. I already have five stories from people like you, and I've just
started collecting. I want 50. There's safety in numbers, and this form of
civil disobedience is the moral thing to do.
>
> Two, we can design. We need to figure out how to re-engineer the internet
to prevent this kind of wholesale spying. We need new techniques to prevent
communications intermediaries from leaking private information.
>
> We can make surveillance expensive again. In particular, we need open
protocols, open implementations, open systems – these will be harder for
the NSA to subvert.
>
> The Internet Engineering Task Force, the group that defines the standards
that make the internet run, has a meeting planned for early November in
Vancouver. This group needs dedicate its next meeting to this task. This is
an emergency, and demands an emergency response.
> 
>
> The gauntlet is in our face. What are we going to do about it?
>
>

Is there a standards gap or an implementation gap?

All Tor, all TLS, all PGP,  all DANE all the time?

And dont forget about this
http://www.zdnet.com/nokia-hijacks-mobile-browser-traffic-decrypts-https-data-709655/

I like this post below, just accept the risk that there is no expectation
of privacy. The snoops have optical taps and all the private keys.  And the
T&Cs for most public email services, social networks,  maps, hospitals,
airport wifi... make it clear your data is not private.

http://www.schneier.com/blog/archives/2013/09/our_newfound_fe.html

CB

> --
> Dean Willis

Re: Not Listening to the Ops Customer

[cb.list6]

On Jun 1, 2013 11:52 AM, "John C Klensin"  wrote:
>
> Brian,
>
> I really need to stop posting to this thread -- I have other
> things to do and I don't believe the conversation is leading to
> anything actionable.  Second-guessing is fairly useless at this
> point and there are at least a few things that we know in
> retrospect that we couldn't have known in 1993-1995.  I continue
> to believe that many of the IPv6 impediments have been economic
> and deployment policy issues that we did understand in 1993 but
> didn't pay enough attention to, but some of the technical stuff
> was, and is, more complicated.  On the technical side, I believe
> that there was a general belief in 1993 that we would be able to
> map out a unified, clear, transition strategy for IPv6 and give
> simple advice about it.  In retrospect, that was probably
> naive... and I believe that confused messages about transition,
> especially to people who won't make their deployment  decisions
> based on complex and subtle technical issues, have been part of
> the problem.
>

I think there is something here that is interesting, and that is the
interplay between paper design, evolution, and ultimately the emergent
complex dynamical system we call the internet ... which is almost
completely zero compliant to the e2e principle.  Not that e2e is the wrong
principle, but ipv4 could not support it as of 10+ years ago. Hence, nearly
every internet node is behind a stateful device (cpe or cgn nat) or server
load balancer. There is also widespread disbelief in how dns operates in
the real world (not everyone gets the same answer).

Yet, corners of the ietf call this real world internet of middleboxes as
broken. As some of it is broken, so you have things like SPDY and
ICE/STUN/TURN/464XLAT/MAP/6RD to bust through it.  Mutation happens.

That said, the teaching moment here is look back and realize the internet
was not engineered, if was emerged.

Given that the internet is not engineered and that it is a greedy
collection of self optimizing nodes that mutate, how do we make it go fast,
bigger, better given the few levers we have.

CB

> More inline.
>
> --On Saturday, June 01, 2013 16:35 +1200 Brian E Carpenter
>  wrote:
>
> >...
> > It was more complicated. I was actually running a team that
> > ran site network ops at the time, and (since DHCP was not yet
> > deployable), IPv4 was then a serious nuisance to manage,
> > compared say to Novell Netware and, even, Appletalk. There
> > were good reasons we wanted stateless auto-configuration and
> > unlimited subnet size, to mention two IPv6 bells and whistles.
> > If DHCP had already been deployed, our opinion might have been
> > different.
>
> Yes, as I think Vint says, it is always more complicated.  But
> translating the above into the perspective of a decision-maker
> who has to decide if, when, and how to deploy IPv6, those
> requirements weren't very compelling.  Some of the organizations
> that had the need were already running some member of the family
> of LAN protocols in which every node continually broadcast its
> identity and location, or were getting by with BOOTP.  Others
> just didn't perceive the problem as a need rather than, at most,
> an inconvenience.  IPv6 would have made things better, but
> almost no one actually was going to convert to it for that
> reason given the other costs of conversion.   Then given your
> explanation, IETF came along with an IPv6-killer in the form of
> DHCP and reduced the motivation further.
>
> The standardization and deployment of DHCP was entirely
> reasonable.  But we knew that DHCP was coming -- RFC 1531 was
> published several months before even the IPng solicitation in
> RFC 1550 and the DHC WG had been around, IIR, some time longer
> -- so assuming that the configuration issues were going to be a
> major driver to IPv6 doesn't speak well for the IETF's ability
> to think about and understand complete systems and relationships
> among protocols a decade ago (I have no reason to claim we have
> gotten either better or worse -- so much for cross-area review
> at the systems, rather than nits, details, and religion, levels).
>
> > It turns out that as soon as you envisage a network in which
> > some nodes only support 32 bit addresses and other nodes can't
> > get a globally unique 32 bit address, you are forced into a
> > world of hurt that requires some combination of NAT, tunnels
> > and dual-stack. That is completely independent of the design of
> > IPng, and we knew it 1994.
>
> Sorry, Brian.  I may just be naive, but I see a difference
> between the same protocol with an extended address format and a
> different protocol that coexists more or less well.   They may
> be formally no different, but the transition strategy
> implications are, IMO, very different in part because the former
> involves only a single address space with issues accessing part
> of it while the latter implies everything we have seen played
> out in recent years.   In p

Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)

[cb.list6]

On May 27, 2013 10:56 AM, "Henning Schulzrinne"  wrote:
>
> Agreed - this is not so much about standards, but developer awareness. If
we write any "how to" or similar informational documents, they should
probably contain that type of discussion.
>
> There is a browser aspect, however: Right now, users only have a binary
choice about location disclosure, even though I suspect many users would be
fine with "location disclosure for 911 only", not "disclose my fine-grained
location for any purpose you like".
>

WebRTC is just a website in many respects.

I would like to see telcos get out of this starngely engineered and
regulated world and just be a "dumb pipe" for smart emergency services

And, in its place, the relevant emergergency response stakeholders
deblvelop 911.gov and when i need help i go to 911.gov and have a webrtc
call to my relevant emergency agency, or sip://h...@911.gov .

And like  root CA certs, the location disclosure is already approved by the
browser vendors (giving user choices is not advised in emergencies)

CB
> On May 27, 2013, at 1:51 PM, Richard Barnes  wrote:
>
>> Even for location delivery, there's not that much to say at the
standards layer.
>>
>> For *delivery*, the story is the same as with signaling.  Either the
RTCWeb VoIP service can translate the location information to comply with
RFC 6442, or the PSAP can just build a web app that collects it however it
likes.
>>
>> For *determination*, it's about the browser.  You can do browser-based
geolocation today, to "OK" quality.  Or the browser could implement the
GEOPRIV protocols to benefit from network-provided location.
>>
>> All that's about implementation/deployment though.  I don't really see
any new standards there.
>>
>> --Richard
>>
>>
>>
>> On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne <
h...@cs.columbia.edu> wrote:
>>>
>>> The most difficult part for any emergency calling system is location
delivery. WebRTC probably doesn't have much impact on emergency calls if
all the calls traverse a server of some kind and if the caller location can
be looked up based on caller IP addresses, but once you have the end system
involved in location determination (e.g., for mobile devices or for
DHCP-delivered location), it has to know when a call is an emergency call
as you otherwise end up providing location for every call, which is
non-ideal from a privacy and battery perspective.
>>>
>>> At least in the US, many of the WebRTC services would be considered
"interconnected VoIP", so they are indeed subject to 911 obligations.
>>>
>>> Henning
>>>
>>> On May 26, 2013, at 3:57 PM, Richard Barnes  wrote:
>>>
 Indeed, there has already been some coordination between the groups,
going back about a year:
 
 

 So my read of the situation is much less dire than James's.  As I
understand it, the upshot of the initial coordination discussions is that
there's not a single, clear "RTCWEB+ECRIT" story.  Instead, there are a few
ways you can put them together.  In the short run, without upgrading PSAPs,
RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP,
either at the server, or at the client using something like
SIP-over-WebSockets.  In the long run, PSAPs can just advertise an RTCWEB
service like they would advertise a SIP service today (in LoST).  Neither
of these is incompatible with RTCWEB or ECRIT as they're being specified
today.

 I expect there are probably some ECRIT considerations that aren't
naturally supported in RTCWEB.  Things like real-time text come to mind.
 However, it doesn't seem to me that there's gross incompatibility.

 --Richard




 On Sat, May 25, 2013 at 10:18 AM, John C Klensin 
wrote:
>
>
>
> --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko
>  wrote:
>
> >...
> > I didn't know about the details of the emergency
> > communications situation. But it is always difficult to
> > balance getting something out early vs. complete. I know how
> > much pressure there is on the working groups to keep up with
> > things actually happening in the browsers and organisations
> > setting up to use this technology. Do you think the retrofit
> > will be problematic, and do you have a specific suggestion
> > about what should be included today?
>
> Jari,
>
> James will probably have a different answer and perspective, but
> I suggest that retrofits of security-sensitive features are so
> often problematic to make "always" not much of an exaggeration.
>
> I don't think there is any general solution to the "early vs.
> complete" tradeoff [1], nor, as long as we keep trying to deal
> with things as collections of disconnected pieces rather than
> systems, to the issues created by WGs with significant overlaps
> in either scope or 

Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[cb.list6]

On May 10, 2013 11:51 AM, "SM"  wrote:
>
> At 16:06 16-04-2013, The IESG wrote:
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'The Internet Numbers Registry System'
>>as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be
>
>
> This draft is well-written and it is a significant improvement compared
to the previous version.
>
> In Section 2:
>
>   "As such, allocations must be made in accordance with the operational
>needs of those running the networks that make use of these number
>resources and by taking into consideration pool limitations at the
>time of allocation."
>
> The global IPv4 address pool is currently depleted.  Two RIR regions are
in IPv4 exhaustion phase.  There is a proposal in the RIPE region to remove
"need" [1].  I gather that this new version of the Internet Numbers
Registry System looks towards a future where hosts are IPv6 accessible.
 Given that the free IPv6 address pool is very large and that IP addresses
are not free, what is the rationale for keeping allocations in accordance
with operational needs?
>

I disagree with need based assignment and believe this draft should remove
all such language

The need based policy is not equitable and is nothing but a drag in the
post ipv4 exhaust world.

I have made a case for moving away from need basis here,
http://lists.arin.net/pipermail/arin-ppml/2013-April/026592.html

The ietf should really take the time to review what the rirs have done and
if their mandate needs to be updated.

Ipv4 belongs to the market and ipv6 does not have scarcity issues.

CB


>   "Registration Accuracy: A core requirement of the Internet
>Numbers Registry System is to maintain a registry of
>allocations to ensure uniqueness and to provide accurate
>registration information of those allocations in order to
>meet a variety of operational requirements."
>
> There isn't any mention of privacy [2] considerations in the draft.  Is
it up to the IETF to set up a one-stop shop for personal data requests?
>
> Regards,
> -sm
>
> 1. https://www.ripe.net/ripe/policies/proposals/2013-03
> 2. http://lists.arin.net/pipermail/arin-ppml/2012-April/024596.html