gmane.network.ipv6.hackers

Re: opportunistic encryption in IPv6

Mark Smith — 2013-06-16T00:41:45




----- Original Message -----

BTNS is at the IP layer, as it is a form of IPsec, and is therefore host to host, for as long as the hosts maintain the IPsec session, . This means that all IP traffic traffic between the hosts is encrypted. This results in encryption of traffic for all applications that don't currently encrypt. Yes it would be an overhead for already encrypted application traffic, but that is probably in the minority.


Well, as the name suggests, it is Better Than Nothing.


>

Re: ipv6hackers meeting in Berlin (July 28th, 2013)

Dan York — 2013-06-14T13:45:15



Done.  :-)

Blog post at:

http://www.internetsociety.org/deploy360/blog/2013/06/ipv6hackers-group-to-
meet-in-berlin-on-july-28-2013/



Social media links (please feel free to retweet/share/+1/etc.)

https://twitter.com/Deploy360/status/345534617450840064


https://www.facebook.com/Deploy360/posts/605583726133128


https://plus.google.com/b/100600212961472655878/100600212961472655878/posts
/doeWYnQTpme


and in the IPv6 group on G+:
https://plus.google.com/b/100600212961472655878/100600212961472655878/posts
/H56sSvW8ebk



Also on HN and Reddit (upvotes welcome on both :-) )

https://news.ycombinator.com/item?id=5879828


http://www.reddit.com/r/ipv6/comments/1gc54h/ipv6hackers_group_to_meet_in_b
erlin_on_july_28/


Hopefully this helps...
Dan


--
Dan York
Senior Content Strategist, Internet Society
york-pYXoxzOOsG8< at >public.gmane.org <mailto:york-pYXoxzOOsG8< at >public.gmane.org>   +1-802-735-1624
Jabber: york-qpNhCKirwin9DtjTS/Z7tA< at >public.gmane.org <mailto:york-qpNhCKirwin9DtjTS/Z7tA< at >public.gmane.org>
Skyp

Re: opportunistic encryption in IPv6

S.P.Zeidler — 2013-06-14T08:05:30

Hi,

Thus wrote Tim (tim-security-BnXP7hVpaY90D0fKVHhM9EB+6BGkLq7r< at >public.gmane.org):


Yes and no; if we had long sessions that weren't encrypted anyway,
it might help you detect that someone has started to MitM your
existing conversation.
Given that long term sessions are the exception rather than the norm,
that will not often be the case though.

Also I wonder what traffic exactly is supposed to get opportunistically
encrypted that isn't encrypted or at least encryptable already?


So if I visit a URL promising "cute kittens!", I endorse the identity of
the site? even though I don't care a figs' leaf about the site identity?
That does not seem particularily wise to me.

regards,
spz

Re: ipv6hackers meeting in Berlin (July 28th, 2013)

Fernando Gont — 2013-06-13T23:14:41

Hi, Dan,

On 06/13/2013 02:30 PM, Dan York wrote:

Yes, please do so!




Thanks for the offer, and thanks for double-checking, too!

Cheers,

Re: ipv6hackers meeting in Berlin (July 28th, 2013)

Dan York — 2013-06-13T12:30:16

Fernando,

Do you want this gathering publicized more widely?  I.e. would you like me
to put up a blog post about it on Deploy360? circulate it in social media,
etc?

I'm glad to do so... but if you want to just spread the word among mailing
lists I won't.

Dan

--
Dan York
Senior Content Strategist, Internet Society
york-pYXoxzOOsG8< at >public.gmane.org <mailto:york-pYXoxzOOsG8< at >public.gmane.org>   +1-802-735-1624
Jabber: york-qpNhCKirwin9DtjTS/Z7tA< at >public.gmane.org <mailto:york-qpNhCKirwin9DtjTS/Z7tA< at >public.gmane.org>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/




On 6/13/13 7:03 AM, "Fernando Gont" <fgont-hxuqIv1aByuEK/hMebVsMw< at >public.gmane.org> wrote:

ipv6hackers meeting in Berlin (July 28th, 2013)

Fernando Gont — 2013-06-13T11:03:59

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

We're planning to have our first in-person meeting on July 28th, 2013,
in Berlin (most likely in the afternoon, between lunch and the IETF
welcome reception). The venue would be either the IETF venue
(InterContinental Berlin), or some nearby hotel/room (to be confirmed
soon).

We're planning to have some presentations (which MUST be accompanied
with code :-) ), and might also have an IPv6 mini-hackathon (i.e.,
work on code, test implementations, try stuff).

In order to plan for the meeting, we'd need to have some indication of
how many people would attend, whether they would have stuff to
present, etc. So I've set up a very short on-line survey to help us
plan for the meeting.

If you're interested, please take 5 minutes to complete the survey at:
<https://www.surveymonkey.com/s/FFL386K>

Thanks!

Best regards,
- -- 
Fernando Gont
SI6 Networks
e-mail: fgont-hxuqIv1aByuEK/hMebVsMw< at >public.gmane.org
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55

Re: [Freedombox-discuss] BTNS on Freedombox

Eugen Leitl — 2013-06-13T06:23:28

Any Debian developers listening?

----- Forwarded message from Jonas Smedegaard <dr-7wbikhHcsNQ< at >public.gmane.org> -----

Date: Thu, 13 Jun 2013 01:28:18 +0200
From: Jonas Smedegaard <dr-7wbikhHcsNQ< at >public.gmane.org>
To: Eugen Leitl <eugen-WaCMhLcPx2TYtjvyW6yDsg< at >public.gmane.org>, freedombox-discuss-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB< at >public.gmane.org
Subject: Re: [Freedombox-discuss] BTNS on Freedombox
User-Agent: alot/0.3.4

Quoting Eugen Leitl (2013-06-12 20:47:07)

Thanks for clarifying.

Sounds cool, but also sounds like something that needs maturing.

FreedomBox is a server engineered by us geeks to be owned fully by 
non-geeks, and therefore have *no* system administrator.  That means 
there is even less room for failure than the servers we run ourselves.

I strongly believe that any and all pieces that we put into FreedomBox 
should already be in common use among geeks.  Eat our own dog food, so 
to speak.  To me that means we can *only* include in FreedomBox what is 
in Debian.

So way forward for this

Slideware of recent presentations about IPv6 security

Fernando Gont — 2013-06-12T23:37:27

Folks,

FYI, the slideware of two recent presentations is available online:

* "Security Assessment of IPv6 Networks and Firewalls", presented at the
German IPv6 Kongress (http://www.ipv6-kongress.de/) in Frankfurt/Main,
June 6-7, 2013.

Slideware available at:
<http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv6-security-assessment.pdf>

We did this talk together with Marc Heuse. First time we presented
together and we crafted the slideware a couple of hours before the talk.
 -- we should present together again!



* "IPv6 Network Reconnaissance: Theory & Practice". presented at
CONFidence 2013 (http://2013.confidence.org.pl/). May 28-29, 2013.
Krakow, Poland.

Slideware available at:
<http://www.si6networks.com/presentations/confidence2013/fgont-confidence2013-ipv6-network-reconnaissance.pdf>


P.S.: I'd like to express gratitude to the conference organizers, and
Enno Rey, for the warm reception, and the great time.

Thanks!

Best regards,

Re: [cryptography] opportunistic encryption in IPv6

Eugen Leitl — 2013-06-12T16:18:29

----- Forwarded message from Will Yager <will.yager-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> -----

Date: Wed, 12 Jun 2013 11:08:27 -0500
From: Will Yager <will.yager-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To: cryptography-JWVWRpNfo5ceIZ0/mPfg9Q< at >public.gmane.org
Subject: Re: [cryptography] [ipv6hackers] opportunistic encryption in IPv6
X-Mailer: iPhone Mail (10B146)

The process of randomly generating and calculating a public key for every brute-force attempt will slow the process considerably. However, for further key stretching, perhaps many iterations of SHA-* et al. is not the best option. Since web servers may be processing thousands of new connections per second, thousands of iterations of SHA and co. per
connection may be prohibitively time-intensive for servers to implement. At the same time, attackers with GPUs/FPGAs/ASICs will have an advantage of several orders of magnitude. Perhaps in this case, it would be wise to leverage a universally slow algorithm like Scrypt. It's not more difficult to im

Re: opportunistic encryption in IPv6

Eugen Leitl — 2013-06-12T16:06:36


There is a very important use case for a passive global adversary
where adding active MITM at the core (at full wire speed,
potentially deep underwater so limited on space and power
budget) makes it a) considerably more expensive, possibly prohibitively so 
b) makes tampering in transit fundamentally detectable, 
since no longer passive.

I realize that this is a very poor match for enterprise users.
 

I think that the hard problem is sufficiently hard so it needs
to be pushed back. As soon as you add key management and look
up, especially over the network lookup it's starting to get
both complex and expensive. It's probably easier at higher layers,
up to the application layer.

Re: opportunistic encryption in IPv6

Tim — 2013-06-12T16:34:11

Hi guys,

Long time lurker, seldom poster.

I've read through this whole thread to date and just want to make a
couple of comments.


Here, I just don't understand the logic.  To me, encrypting without
authenticating buys you absolutely nothing, except to burn CPU cycles
and contribute to global warming.  In the *vast* majority of
networking technology we use, modifying data in transit is just as
easy as passively reading data in transit, within a constant factor.
(That is, in a big-O sense, these are the same difficulty.)

SOOOO many different attempts at creating encryption protocols have
utterly failed, and in most cases, it is because the designers have
put the cart before the horse.  They've started with the easy
encryption problem rather than addressing the hard authentication
problem.

Indeed, you may be able to convince the world at some point to adopt
opportunisitic encryption without authentication, since so many people
don't understand that it doesn't buy you anything.  But then they'll
be shocked

Re: opportunistic encryption in IPv6

Eugen Leitl — 2013-06-12T15:19:14


One thing I forgot: carrier-grade NAT breaks BTNS, right?

Re: opportunistic encryption in IPv6

Eugen Leitl — 2013-06-12T15:16:02


In case of cheap consumer "routers" running OpenWRT the actual
setup is minimal (or none, in case you happen to have DHCP).
So if you had BTNS activated out of the box, or available
as tickbox that would considerably ease deployment.
Use of BTNS would be transparent for all devices behind
the consumer NAT box, requiring zero administration on
each device. Am I misunderstanding something, or is this
essentially correct?

How much latency penalty does BTNS add to your session, both
for cases where the opposite system supports BTNS and
when it does? Is there a significant difference between
IPv4 and IPv6 here, or is that below detectability threshold
(say, <5 ms added).


I'm probably just using the wrong term.

Thanks lots, for some reason OE and BTNS has slipped my mind
for a while.

Re: opportunistic encryption in IPv6

Jim Small — 2013-06-12T14:30:03

Hi Eugen,


I see where you're going, but from reviewing the proposal it would seem to require setup on the endpoint.  If setup is required, why not just do OE from the endpoint?  I don't see how a gateway is making it easier in this case - if anything it seems like the gateways add more complexity.


BTNS - you could do for either v4 or v6 but I was thinking v6 with CGAs.


For savvy end users I believe there would be an interest in OE.


Based on my experience in the US market, there would be little interest in OE for the (American) enterprise space.  If an enterprise is going to do something with security, authentication must be a component.  The other factor that you may not have considered is supportability.  By enabling OE, I'm adding complexity and potential problems.  It makes things harder to troubleshoot.  It's also possible it could break some communications.  I'm not convinced the value is sufficient to justify the increased support/troubleshooting requirements.


For OE at the host level I agree

Re: opportunistic encryption in IPv6

Eugen Leitl — 2013-06-12T10:32:32


Correct.


If we want to increase deployment rate, it should be easier in the
residential or enterprise firewall (e.g. rolling it into OpenWRT or pfSense).
Not sure whether NAT is still prevalent in IPv6 deployments --
if it's running as an IPv6 router/firewall instead of NAT 
you'll probably have to handle OE at host level? That would pretty
much kill it.


Is this the BTNS approach, or do you need PKI or DNS access for it to works?
IPv4 or IPv6, or both?


I'm reasonably sure that there is a potentially huge demand for 
passive attack protection for end users and enterprises. If this
could be package-ready for Linux or FreeBSD then eventual deployment
numbers could be considerable.

Re: opportunistic encryption in IPv6

Jim Small — 2013-06-12T03:46:31

Eugen,

I read this again and I apologize for missing the bus.  So the basic idea is how to provide scalable confidentiality to prevent passive eavesdropping.  Going back to the roots of IPv6 - the end to end principal, wouldn't it make more sense to just do OE at the endpoint?  That seems to have the highest chance of adoption.  If Owen and I want to do OE we just enable it on our Linux hosts and away we go.  Do you think there is interest/demand for an OE gateway solution as described in the paper?

--Jim

Re: opportunistic encryption in IPv6

Jim Small — 2013-06-12T03:31:10

True as long as you don't need authentication.  But I have to concede, the whole point of OE is just to encrypt the traffic.


Per RFC 3972, "CGAs are not certified."  I read the RFC as assuming a strong hash and secure private key, once someone uses a CGA someone else can't hijack/impersonate that address.  So they are great for unauthenticated encryption.


True, but I wonder how well this fairs against modern massive parallel GPU crackers.  SHA-1 is a weak hash.  Would be nice to see an update using SHA-2/SHA-3 and to mandate longer key lengths - say >= 2048 bits.  Otherwise doesn't it seem like we're going down the WEP path again?

Still - it's a great point, CGAs do seem well suited for OE if you can live with the limitations.  Is there anything that currently supports this?  I'm wondering how much IPv6 market value this has...

--Jim

Re: opportunistic encryption in IPv6

Owen DeLong — 2013-06-11T19:00:15

On Jun 11, 2013, at 06:55 , Jim Small <jim.small-22trykYRFPg< at >public.gmane.org> wrote:


Interesting. Someone from Micr0$0ft was touting some sort of datacenter-oriented product where all the machines in the datacenter would automatically encrypt all M2M traffic in the manner described above if they shared a common AD domain with appropriate PKI to facilitate it.
I thought they called it Direct Connect or something like that, so perhaps we are talking about different, but similar M$ products?


As long as the two domains coordinate authentication (this must occur in order to have functional authentication anyway), I don't see why the DA techniques, if not the actual product, could not be applied.

Owen

Re: opportunistic encryption in IPv6

Julius Kriukas — 2013-06-11T19:01:07

I believe CGAs solves PKI problem entirely. If using CGAs one does not 
need any PKI or CA certificate at all.

Each node having CGA can give self signed certificate. The certificate 
is used only to extract public key (PK), modifier, collision counter and 
any extension fields.

Extracted information can be used to verify that host address is valid 
CGA with the given public key.

Next step is symmetric key negotiation. If during key negotiation 
messages are encrypted with the specified public key then only node 
having the corresponding private key can decrypt key negotiation messages.

This step ensures that MITM is not possible if you are using CGA 
generated not from your own public/private key pair. If you use your own 
public/private keys then you no longer can easily choose your address.

If using CGA+IPSEC then IKE daemon can do the key negotiation part when 
given authenticated public key.

In SEND PKI is used only to protect from rogue routers. Only 
certificates signed by the CA should be able

Re: opportunistic encryption in IPv6

Jim Small — 2013-06-11T13:55:34

Not exactly.  DA is essentially a transparent VPN that always connects a mobile user to corporate.  Microsoft can allow any to any VPNs within an AD domain but that's more along the lines of what they call domain isolation.


This is great within a single administrative domain.  But it's not a solution for two independent organizations that want to secure traffic with each other.  My impression was that's the point of the paper.

--Jim

Re: opportunistic encryption in IPv6

Eugen Leitl — 2013-06-11T10:57:09

A lightweight, low-security setup would exchange public keys (short ones, ECC)
during session setup. You will need need active (MITM) attacks to
disrupt this, and it is detectable in principle. 

Keys could be ephemeral (one for each session) or cached, and fingerprints
checked. Changed fingerprints could be silently logged, or session setup
denied.

Keys could be stored in a DHT, according with a trust metric which e.g.
uses social graph information for validity.