Hello Greg and Jan and thanks for your insights!

(answering to several messages at once)

  -------------------------------------------------------
On Wed, May 04, 2016 at 07:43:46PM -0400, Greg Troxel wrote:
>   I am uncomfortable about the coda security scheme being a roll-your-own
>   thing.  I would want to look at Kerberos or DTLS.  I realize this is
>   harder than it sounds.

Besides the token size, the security does not look bad.

It is also an advantage, to be able to use Coda without a Kerberos
infrastructure.

>   Whatever the next steps, IPv6 support is a big deal.

I agree. OTOH this is not a showstopper yet.

>   I think it's critical to have a FUSE client so that coda can run
>   anywhere that supports FUSE (the high-level interface, preferably).  I

As Jan commented and I agree, FUSE is unfortunately hardly viable.

A more general alternative would be not going through the kernel
has its own limitations.
There is another fully user space technology which could work well (use
of Proot) but it exists only for Linux. Given the presence of the linux
Coda kernel module we can as well continue to use the module.

>   think it's perfectly ok if performance suffers a bit for this; working
>   at 25% speed is 90% of the utility function for me, if not 95%.

Sure, for portability I would certainly accept this.

>   The last big thing is to make conflict repair more robust, so that
>   normal people rarely lose.  It's quite good already, but the last
>   little bit is likely real work.

+1

>   Coda's behavior of doing a store when one does
>   open-for-write/read/close is really awkward.  Arguably programs should
>   not do that, but they do.

The cost of detecting writes is the need of intercepting them. May be
the cost is not too high if the interception can be shortcut at the first
write and if we manage to put such a change into the upstream kernel(s).
Kernel changes are hard though.

> Note that I'm not using coda any more,

That's a loss for Coda, really.

> despite having started in the 90s
> and continued until 2015 some time.  The two reasons are having to run
> IPsec to be comfortable with security and lack of portability.

I hope you could find Coda attractive again when we improve security
and possibly portability too. Which level of portability is crucial for
you? To open platforms or to closed ones?

  -------------------------------------------------------
On Wed, May 04, 2016 at 08:40:32PM -0400, Jan Harkes wrote:
> On Wed, May 04, 2016 at 11:44:35AM +0200, u-myfx_at_aetey.se wrote:
> > Probably the most apparent one is the limit on the key length in the
> > security layer. It is a hard one too, because the limitation is hardwired
> > in the current protocol.

> Can you point out where the key length is hardwired to a undesirable
> length?

[BTW thanks for the illustrated analysis of the handshake]

> This is either a username (clog/auth2) and the
> shared secret is looked up in the password database, you aren't even
> using this bit because you are using kerberos.

We are using multiple authentication authorities at the same time,
including Kerberos realms _and_ the Coda authentication database.
The security of Coda password authentication is relevant.

> The other client identity
> is the encrypted Coda token, which the client has a plaintext copy of
> and the server is able to decrypt because it (or one of it's peers)
> generated the original.

There is the secret length limitation in the token, which has the same
implications as the key size (I think it was you who pointed out this
matter once upon a time). The key in the database is also short
and is being used without strengthening, for backward compatibility.

> Now at this point the key exchange that Coda uses is using an old
> RPC2_EncryptionKey to store the random bytes of the secret, and this one
> is only 8 lousy bytes

These limitations aside (which are not in your code), you did indeed a
great job when you constructed a respectable security layer, compatible
with the old protocol.

But those 8-byte limitations, they become too bad now.

There is another potential weakness in the way Coda authentication is
being used. When clients talk to servers or servers connect to each
other, they verify that the other party belongs to the correct realm,
but this might happen to be a different server in the same realm. I guess
mixing the server id into the handshake would eliminate this uncertainty.

If we are going to touch the crypto-related stuff, there is a library
I have special respect for, [Tweet]NaCl.

Do you think we could rely on it in Coda?

  -------------------------------------------------------
On Thu, May 05, 2016 at 12:22:09AM -0400, Jan Harkes wrote:
> On Wed, May 04, 2016 at 07:43:46PM -0400, Greg Troxel wrote:
> >   The last big thing is to make conflict repair more robust, so that
> >   normal people rarely lose.  It's quite good already, but the last
> >   little bit is likely real work.
> 
> I've been thinking long and hard about this. I've pretty much been
> trying to get repair working more reliably ever since I joined CMU.
 ...
> lets look at the pros and cons of (optimistic) replication for a bit.

I see that you are sceptical about the optimistic replication (no
pun intended), you mentioned this also when we talked earlier long ago.

>From my perspective unfortunately it feels differently. I see optimistic
replication as one of the crucially useful features in Coda. It allows
a different and convenient system architecture (based on Coda)
and corresponding system administration.

> Now when there is no optimistic replication:
 ...

This looks like the way AFS took. Surely this does bring certain
advantages but buys them by losing other ones. Optimistic replication
was one of the reasons we chose Coda before OpenAFS. This was not the
only reason but an important one.

> with the available manpower might just hit that magic 10
> year window that Rune was talking about.

This means that the repair improvements may have to wait, we
can live with the status quo.

Some other mentioned issues will soon become hard to live with,
they have to get the manpower in the first hand. Sigh.

Thanks again for the comments!

Regards,
Rune