Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [ipv6hackers] opportunistic encryption in IPv6

Eugen Leitl eugen at leitl.org
Wed Jun 12 08:59:38 PDT 2013


----- Forwarded message from Tim <tim-security at sentinelchicken.org> -----

Date: Wed, 12 Jun 2013 09:34:11 -0700
From: Tim <tim-security at sentinelchicken.org>
To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
User-Agent: Mutt/1.5.20 (2009-06-14)
Reply-To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>

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.

> 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.

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 when the first guy writes and releases a MitM tool for it.


Now, does this mean authentication is a black-and-white matter?  No.
Currently the whole world relies on SSL/TLS's PKI, which has been
shown to be quite weak, especially in the face of government meddling.
The ways in which SSL/TLS is used adds more weaknesses.  But at some
level, we get by.  It is ok, to have weak authentication so long as
you have a way to gradually build the trust of an entity's identity
from that.

As an aside: the idea embodied in CGAs is a powerful one:  By making
my address my key (signature), I'm implicitly binding my key to my
protocol. However, CGAs address this problem at network layer, not at
the human layer.  So all it takes to bypass it is to MitM the protocol
that hands out addresses for hosts.  However, as a building block, it
could be useful.  Also, for those who aren't familiar with it, I
strongly urge you to read up on Identity Based Encryption, where any
string can be a public key, within a predefined authentication realm.


Regarding the earlier comparison of different PKIs, I think we need
something that merges some of the concepts of webs of trust with what
we're using right now in the TLS PKI.  Let me throw out an outline of
what I think would work better and has a chance at adoption:

  - Certificates can be signed by multiple CAs.  The number and
    quality of signatures determines the level of trust of a
    certificate.

  - The act of communicating with a node causes their key (or CA's
    key) to be signed and that signature to be published
    automatically.  The logic is, if you trusted a node's identity
    once, then you should share the knowledge of that trust. This
    publishing process needs to be anonymized somehow.  There needs to
    be incentives for publishing (think bitcoin).

  - Not everyone is a CA.  Perhaps each major organization would act
    as a CA and sign certificates of other CAs.  Users would leverage
    their org's trust network and not need to deal with signing at and
    endpoint level, though their own org would be aware of
    transactions with new external entities and autosign as necessary.


Many of these ideas have obviously been proposed before and my outline
is very generic, but meant as a starting point for discussion.  Also,
I realize that I've veered away from IPv6 specifically, but I think
any discussion of authentication needs to start with people, not
protocols, and then trickle down to the protocol level, not the other
way around.

Cheers,
tim
_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5



More information about the liberationtech mailing list