On Tue, Dec 20, 2005 at 09:03:50AM -0500, Greg Troxel wrote:
> Josef Wolf <jw AT raven.inka DOT de> writes:
> > On Mon, Dec 19, 2005 at 12:56:26PM -0500, Greg Troxel wrote:

> > > I think the essence is that while both are encryption, one is applied
> > > to transport and one to storage.
> > Is it really _that_ different?  IMHO, a public-key method encrypted on
> > the client would be good for both, transport _and_ storage.
> 
> Yes, it really is totally different.

I'm still not very convinced.  IMHO, case E has (from the security/safety
perspective) only advantages and no disadvantages when compared to the
other cases.  Let's take a closer look at the use-cases you listed. 

> transport     storage         tag
> no            no              A
> yes           no              B
> no            yes             C
> yes           yes             D       [separate encryption, back to
>                                       clear on server]
> yes           still           E       [client encrypts, server passthrough]

A. This is the trivial case.  If we talk about encryption, this case
   doesn't make any sense at all.  Just don't activate encryption, and
   you're done.
   I don't see why this case deserves any discussion at all.  The
   end-result (if you can read the tape you have access to unencrypted
   data) is identical to case B.  So why not fall back to case B here?

B. If the tapes are stored in a trusted environment, it should be no
   problem to store the private key along with the tapes.  In addition,
   you can store a copy of the key in a safe.
   Technically, it would even be possible to store the key on the amanda
   tapes (in a preamble).  This could even be automatable by an amanda
   config-option (or holding the priv-keys on an un-encrypted DLE).
   On first sight, such a solution might look like a disadvantage, but
   please keep reading.

C. If you are storing encrypted anyway, why not transporting encrypted
   too?  Most amanda-installations have lots of clients anyway, so putting
   the burdon of encryption on the server will probaly slow down backups
   on most installations.  I don't see any benefits of this case.

D. What would be the benefit of this case?  I see only disadvantages here:
   - high load on tapeserver.
   - more surface for attackers.

E. This is the case I would prefer.  Obviosly, I don't see any
   disadvantages here ;-)  But I am pretty sure someone on this list will
   be able to enlighten me in the near future ;-)

> In scenarios A and C, and eavesdropper on the network can observe the
> data.  In B D and E an eavesdropper cannot.

So E has no disadvantages here.

> In secenarios A and B, one can retrieve the data from backup tapes
> without keying material.   This is perhaps obvious, but very important
> for backups.

Should be no problem for E as long as you store the key along with the
tapes or even _on_ the tapes.

> In C, D, and E, the backup tapes are encrypted.  Thus, one could store
> them someplace where you trust people not to destroy them but you
> don't trust them to read them.   This can make some sense for
> particularly sensitive data.

Again, no disadvantages for E here.

> In E, the backup data doesn't appear on the server in plaintext.  This
> can be useful for backing up clients with particularly sensitive
> data.  To really make sense, the client should be configured so that
> it will only honor dump requests to a preconfigured set of public
> keys.

Clearly, only E can achieve that.

> Note that any of these scenarios can be implemented with symmetric
> encryption (e.g. AES) or public key techniques (e.g. OpenPGP with RSA
> used to encrypt an AES key used for the bulk data, or IKE).  An
> OpenPGP approach is certainly easier to manage for storage, where one
> needs to be able to decrypt backups much later in time.  For
> transport, the backups are decrypted at the server, so techniques like
> Kerberos are workable, in addition to OpenPGP or IPsec/IKE.

It's true there are many ways to implement all that.  But restricting to
client-encrypted-pubkey method would greatly simplify implementation
_and_ configuration.

>From the perspective of an end-user, I would prefer to have only two
additional config-options:

  define dumptype foo {
    foo-bar-dumptype
    crypt-pubkey  /path/to/pubkey-%h-%d  # public  key is on client
    store-privkey /path/to/privkey-%h-%d # private key is on server
  }

In the above, %h (if available) would be replaced by the hostname and %d
by the DLE name.  This makes it possible to have DLE-specific key-pairs,
host-specific key-pairs, or to have one key-pair for the entire amanda
configuration, depending on the security-requirements of the user.

So, to implement the use-cases you mentioned above:

case A: just omit both options.  Or better, use case B, since the
        end-result is identical (if you can read the tapes you have
        the private keys, so decrypting is no additional hurdle)
case B: crypt-pubkey foo; store-pubkey bar
case C: crypt-pubkey foo
case D: crypt-pubkey foo
case E: crypt-pubkey foo-%h-%d  # for particularly sensitive DLEs
        crypt-pubkey foo-%h     # for sensitive hosts
        crypt-pubkey foo        # on the avarage hosts

So all mentioned cases boil down to only two cases: B and E.  For
backwards compatibility case A would be desirable, too.  And all of
those cases can be acomplished by the client-encrypted-pubkey method,
IMHO.  So why complicating things more than necessary?

-- 
No software patents in Europe -- http://nosoftwarepatents.com
-- Josef Wolf -- jw AT raven.inka DOT de --