[ipv6hackers] opportunistic encryption in IPv6

[Eugen Leitl]

Any idea why opportunistic encryption for IPv6
(e.g. http://www.inrialpes.fr/planete/people/chneuman/OE.html )
was never made ready for production?
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

[Owen DeLong]

Because hardly anyone has the PKI that would be necessary to make it actually work?

Owen

[Jim Small]

Hi Eugen,

I took a quick look at this - a very interesting idea. I see a few issues that I didn't see answers to:
* Paper references a host using MLD to join an Anycast group - but AFAIK, this is not in the standards (was a draft that appeared to die) and not supported
* Says PKI isn't good, but then uses a form of it as part of the solution

The fundamental challenge for encryption is key distribution and management:
* How do I authenticate the intended recipient(s)?
* How do I distribute a key without letting anyone except the intended recipient(s) get it?
* How do I manage the key to periodically change it while keeping it confidential?
* How do I notify the recipient if the key was compromised or is otherwise invalid?

If this paper addressed this I missed it. The paper seems to imply that hosts get an RSA key pair but I didn't see how. If I'm relying on public keys, how do I know they're legitimate?

The other challenge I see with this paper is that the "simple" endpoints must obtain a key pair, configure a CGA, and take explicit action to opt-in to encryption. Given the target I think this is unlikely to succeed. I think this is an interesting idea. For it to have a chance of adoption I think it would have to be transparent to the endpoints.

--Jim

[Owen DeLong]

> The fundamental challenge for encryption is key distribution and management:
> * How do I authenticate the intended recipient(s)?

This is a traditional challenge with many traditional solutions, all of which have tradeoffs, especially in M2M communications.

> * How do I distribute a key without letting anyone except the intended recipient(s) get it?

DH pretty well solves this, no?

> * How do I manage the key to periodically change it while keeping it confidential?

Again, DH with PFS makes this a solved problem AFAIK.

> * How do I notify the recipient if the key was compromised or is otherwise invalid?

This doesn't seem all that hard so long as a rekey instruction is built into the protocol. I believe that's already the case with IPSEC SAs, no?

Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's "direct-connect" or whatever they call it product is quite a bit more viable.

It depends on AD as a PKI distribution mechanism for authentication.


Owen

[Jim Small]

Hi Owen,

> > The fundamental challenge for encryption is key distribution and
> management:
> > * How do I authenticate the intended recipient(s)?
>
> This is a traditional challenge with many traditional solutions, all of which have
> tradeoffs, especially in M2M communications.
>
> > * How do I distribute a key without letting anyone except the intended
> recipient(s) get it?
>
> DH pretty well solves this, no?

Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. So I think there would be some value in a keying system that allows some kind of controlled federation without having to depend on pre-shared keys, PKI, or DNSSec.

> > * How do I manage the key to periodically change it while keeping it
> confidential?
>
> Again, DH with PFS makes this a solved problem AFAIK.

True - but only after the initial hurdle of having a pre-shared key or RSA key pair.

> > * How do I notify the recipient if the key was compromised or is otherwise
> invalid?
>
> This doesn't seem all that hard so long as a rekey instruction is built into the
> protocol. I believe that's already the case with IPSEC SAs, no?

Well - if we take DH, it's true once we've established a connection. What about if we haven't? Really the question I'm asking - if we have two independent parties, how do they validate each other without a trusted 3rd party? Current options:
* pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated)
* PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments
* DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption
* Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario

Did I miss any viable wide spread options? I know there are lots of theoretical ones but I'm talking about significantly deployed ones - say used by at least 1 million parties.

> Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's "direct-
> connect" or whatever they call it product is quite a bit more viable.
> It depends on AD as a PKI distribution mechanism for authentication.

DirectAccess is neat - but it's not exactly a break through. DA is just a service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of certificate-based IPsec leveraging Windows Active Directory provisioning.

There are some good ideas in this paper. I just think there are some things missing - at least from my cursory reading of it.

--Jim

[Mark Smith]

----- Original Message -----
> From: Jim Small <jim....@cdw.com>
> To: IPv6 Hackers Mailing List <ipv6h...@lists.si6networks.com>
> Cc:
> Sent: Tuesday, 11 June 2013 11:02 AM
> Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
>
> Hi Owen,
>
>> > The fundamental challenge for encryption is key distribution and
>> management:
>> > * How do I authenticate the intended recipient(s)?
>>
>> This is a traditional challenge with many traditional solutions, all of
> which have
>> tradeoffs, especially in M2M communications.
>>
>> > * How do I distribute a key without letting anyone except the intended
>> recipient(s) get it?
>>
>> DH pretty well solves this, no?
>
> Yes and no.  DH is a good answer, but IKE/IPsec still requires pre-shared keys
> or RSA key pairs to start with.

Don't think so anymore.

"Better-Than-Nothing Security: An Unauthenticated Mode of IPsec"
http://tools.ietf.org/html/rfc5386


Don't know if there are any implementations available.

[Jim Small]

Hi Mark,

> >> > The fundamental challenge for encryption is key distribution and
> >> management:
> >> > * How do I authenticate the intended recipient(s)?

> >> > * How do I distribute a key without letting anyone except the
> >> intended recipient(s) get it?
> >>
> >> DH pretty well solves this, no?
> >
> > Yes and no.  DH is a good answer, but IKE/IPsec still requires
> > pre-shared keys or RSA key pairs to start with.
>
> Don't think so anymore.
>
> "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec"
> http://tools.ietf.org/html/rfc5386

Thanks - I was not aware of that. So BTNS is interesting - but it doesn't solve the above problems. Per the RFC, BTNS doesn't authenticate peers. It would seem that secure key distribution (maintain confidentiality, integrity, and authentication) remains a vexing problem.

Here's an interesting question more relevant to the list and the paper though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone on the list think that CGAs could provide a useful competitive advantage for IPv6 over IPv4? Are these a useful building block? One thing I wonder about is a 64 bit hash is pretty small - I wonder if that is sufficiently complex to provide security for the coming decade+? PKI CAs using SCEP for enrollment/management work pretty well. If you could get a key pair from DHCP or as a function of using a directory service, use it to generate a CGA, and then use that just for authentication it would already be fantastic. Just being confident that an address is authentic and not spoofed is a huge improvement over the current state for Internet security.

Thoughts?
--Jim

[Owen DeLong]

On Jun 10, 2013, at 18:02 , Jim Small <jim....@cdw.com> wrote:

> Hi Owen,
>
>>> The fundamental challenge for encryption is key distribution and
>> management:
>>> * How do I authenticate the intended recipient(s)?
>>
>> This is a traditional challenge with many traditional solutions, all of which have
>> tradeoffs, especially in M2M communications.
>>
>>> * How do I distribute a key without letting anyone except the intended
>> recipient(s) get it?
>>
>> DH pretty well solves this, no?
>
> Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. So I think there would be some value in a keying system that allows some kind of controlled federation without having to depend on pre-shared keys, PKI, or DNSSec.
>

If you don't have pre-shared public keys through a trusted external channel, then you CANNOT trust the keys for authentication of the other side.

If you don't care about using the key for authentication, then IKE DH does (at least on most devices I've worked with) have an ability to use a randomly generated key.

>>> * How do I manage the key to periodically change it while keeping it
>> confidential?
>>
>> Again, DH with PFS makes this a solved problem AFAIK.
>
> True - but only after the initial hurdle of having a pre-shared key or RSA key pair.
>

Some systems I've worked with in the past use this method:

1. Each system generates a random symmetric encryption key appropriate for
the cipher to be used.

2. The systems exchange public keys in the clear (if they don't already know
them).

3. Each system uses the remote public key and it's own private key to sign
and encrypt the generated random key.

4. Each system transmits the encrypted generated random key to the other.

5. The key generated by A is used for the A->B SA. The key generated by B
is used for the B->A SA.

>>> * How do I notify the recipient if the key was compromised or is otherwise
>> invalid?
>>
>> This doesn't seem all that hard so long as a rekey instruction is built into the
>> protocol. I believe that's already the case with IPSEC SAs, no?
>
> Well - if we take DH, it's true once we've established a connection. What about if we haven't? Really the question I'm asking - if we have two independent parties, how do they validate each other without a trusted 3rd party? Current options:

I believe it has been mathematically proven that you cannot.

> * pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated)

Any pre-shared key mechanism that does not involve a trusted third party that can validate both primary parties is inherently insecure.

> * PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments

Depends on the PKI. A private PKI that is reliable is difficult to set up, but if done right does not necessarily suffer from all that many flaws. A WoT style PKI has a number of flaws. Certificates signed by "trusted CAs are obviously fraught with issues because there does not exist a CA with truly good practices."

> * DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption

I don't see how DNSSec would actually help this issue. I can see a few ways you could add things to signed TXT records, but at that point, you're trusting the DNS Delegation signers as the third party in the definition above. Obviously this means that the security is only as good as the DNS delegators from the root down to the last delegation in the chain. (weakest link)

> * Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario

And in the scenario I mentioned, I believe that AD performs this role within the domain, no?
Obviously Micr0$0ft is not my forte, so I won't pretend I know all the details, but I believe that's one of the objects inherent in the AD data structures for each machine/person, no?

> Did I miss any viable wide spread options? I know there are lots of theoretical ones but I'm talking about significantly deployed ones - say used by at least 1 million parties.

I don't know how many are using the Micr0$0ft solution or not. I would expect you to have better insight into that than I.

It's a very strange world when I'm actually suggesting that Micr0$0ft's current solution is a model people should look at for future implementations.

>> Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's "direct-
>> connect" or whatever they call it product is quite a bit more viable.
>> It depends on AD as a PKI distribution mechanism for authentication.
>
> DirectAccess is neat - but it's not exactly a break through. DA is just a service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of certificate-based IPsec leveraging Windows Active Directory provisioning.

But doesn't that amount to opportunistic encryption once it is implemented? As I understand it, any host pair within the AD domain will establish an IPv6 IPSEC SA bidirectionally and send all traffic for the other host through that channel (IPv4 and IPv6) rather than in clear text.

Doesn't that pretty well define "opportunistic encryption"? What am I missing.

I wasn't claiming it was a breakthrough or any sort of fantastic technology. Merely that it was a solution using existing tools that seemed to achieve the overall goals stated in the ID that was referenced.

> There are some good ideas in this paper. I just think there are some things missing - at least from my cursory reading of it.

Hence my suggestion that DA was running code that seemed to do everything the paper set out to do.

Owen

[Eugen Leitl]

On Mon, Jun 10, 2013 at 03:12:59PM -0700, Owen DeLong wrote:
> Because hardly anyone has the PKI that would be necessary to make it actually work?

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.

[Jim Small]

> >> Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's
> >> "direct- connect" or whatever they call it product is quite a bit more
> viable.
> >> It depends on AD as a PKI distribution mechanism for authentication.
> >
> > DirectAccess is neat - but it's not exactly a break through. DA is just a
> service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good
> provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of
> certificate-based IPsec leveraging Windows Active Directory provisioning.
>
> But doesn't that amount to opportunistic encryption once it is implemented?
> As I understand it, any host pair within the AD domain will establish an IPv6
> IPSEC SA bidirectionally and send all traffic for the other host through that
> channel (IPv4 and IPv6) rather than in clear text.

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.

> Doesn't that pretty well define "opportunistic encryption"? What am I
> missing.

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

[Julius Kriukas]

On 06/11/2013 07:27 AM, Jim Small wrote:
> Here's an interesting question more relevant to the list and the paper though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone on the list think that CGAs could provide a useful competitive advantage for IPv6 over IPv4? Are these a useful building block?

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 to send router advertisements.

TLDR:
For address authentication (protection against MITM) when using CGA no
PKI is needed.

CGAs is holy grail for opportunistic encryption. Node can immediately
start using opportunistic encryption by generating self signed
certificate and CGA.

> One thing I wonder about is a 64 bit hash is pretty small - I wonder
> if that is sufficiently complex to provide security for the coming
> decade+?

When generating CGA you can choose security level which allows to slow
down brute force attacks (search for modifiers which would generate
specific CGA address).

Security level is encoded in the first three bits of the address.
Because of that CGAs with lower security does not overlap with stronger
CGAs.


--
Julius Kriukas

[Owen DeLong]

On Jun 11, 2013, at 06:55 , Jim Small <jim....@cdw.com> wrote:

>>>> Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's
>>>> "direct- connect" or whatever they call it product is quite a bit more
>> viable.
>>>> It depends on AD as a PKI distribution mechanism for authentication.
>>>
>>> DirectAccess is neat - but it's not exactly a break through. DA is just a
>> service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good
>> provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of
>> certificate-based IPsec leveraging Windows Active Directory provisioning.
>>
>> But doesn't that amount to opportunistic encryption once it is implemented?
>> As I understand it, any host pair within the AD domain will establish an IPv6
>> IPSEC SA bidirectionally and send all traffic for the other host through that
>> channel (IPv4 and IPv6) rather than in clear text.
>
> 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.
>

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?

>> Doesn't that pretty well define "opportunistic encryption"? What am I
>> missing.
>
> 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.

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

[Jim Small]

> > Here's an interesting question more relevant to the list and the paper
> though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone
> on the list think that CGAs could provide a useful competitive advantage for
> IPv6 over IPv4? Are these a useful building block?
>
> I believe CGAs solves PKI problem entirely. If using CGAs one does not need
> any PKI or CA certificate at all.

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.

> 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 to send router advertisements.
>
> TLDR:
> For address authentication (protection against MITM) when using CGA no
> PKI is needed.

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.

> CGAs is holy grail for opportunistic encryption. Node can immediately start
> using opportunistic encryption by generating self signed certificate and CGA.
>
> > One thing I wonder about is a 64 bit hash is pretty small - I wonder > if that
> is sufficiently complex to provide security for the coming > decade+?
>
> When generating CGA you can choose security level which allows to slow
> down brute force attacks (search for modifiers which would generate specific
> CGA address).
>
> Security level is encoded in the first three bits of the address.
> Because of that CGAs with lower security does not overlap with stronger
> CGAs.

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

[Jim Small]

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

> -----Original Message-----
> From: ipv6hacke...@lists.si6networks.com [mailto:ipv6hackers-
> bou...@lists.si6networks.com] On Behalf Of Eugen Leitl
> Sent: Monday, June 10, 2013 9:24 AM
> To: ipv6h...@lists.si6networks.com

[Eugen Leitl]

On Wed, Jun 12, 2013 at 03:46:31AM +0000, Jim Small wrote:

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

Correct.

> 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

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.

> chance of adoption. If Owen and I want to do OE we just enable it on our

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

> Linux hosts and away we go. Do you think there is interest/demand for an OE
> gateway solution as described in the paper?

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.

[Jim Small]

Hi Eugen,

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

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.

> 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.
>
> > chance of adoption. If Owen and I want to do OE we just enable it on
> > our
>
> Is this the BTNS approach, or do you need PKI or DNS access for it to works?
> IPv4 or IPv6, or both?

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

> > Linux hosts and away we go. Do you think there is interest/demand for
> > an OE gateway solution as described in the paper?
>
> I'm reasonably sure that there is a potentially huge demand for passive
> attack protection for end users

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

> and enterprises.

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.

> If this could be package-

> ready for Linux or FreeBSD then eventual deployment numbers could be
> considerable.

For OE at the host level I agree. For the gateway solution I'm not so sure.

--Jim

[Eugen Leitl]

On Wed, Jun 12, 2013 at 02:30:03PM +0000, Jim Small wrote:

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

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

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

I'm probably just using the wrong term.

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

[Eugen Leitl]

On Wed, Jun 12, 2013 at 05:16:02PM +0200, Eugen Leitl wrote:

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

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

[Tim]

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

[Eugen Leitl]

On Wed, Jun 12, 2013 at 09:34:11AM -0700, Tim wrote:

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

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.

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

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.

[S.P.Zeidler]

Hi,

Thus wrote Tim (tim-se...@sentinelchicken.org):

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

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?

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

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
--
s...@serpens.de (S.P.Zeidler)

[Mark Smith]

----- Original Message -----
> From: S.P.Zeidler <s...@serpens.de>
> To: IPv6 Hackers Mailing List <ipv6h...@lists.si6networks.com>
> Cc:

> Sent: Friday, 14 June 2013 6:05 PM
> Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
>
> Hi,
>
> Thus wrote Tim (tim-se...@sentinelchicken.org):
>
>> 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.
>
> 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.
> 

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.

> Also I wonder what traffic exactly is supposed to get opportunistically
> encrypted that isn't encrypted or at least encryptable already?
>
>>   - 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).
>
> 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.
> 

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