[Telepathy] Spec meeting about SSL and E2E Encryption

[Sjoerd Simons]

Hey,

  Yesterday Simon, Will, Cosicmo, Eitan and myself had a telepathy spec
  meeting about the Encryption and SSL verification spec as proposed by
  respectively Cosicmo and Eitan. Brief notes are below :)

  The two interfaces discussed are available at:
   * http://people.collabora.co.uk/~cosimoc/encryption-spec/spec/org.freedesktop.Telepathy.Channel.Interface.Encryption.DRAFT.html
   * http://people.collabora.co.uk/~cosimoc/encryption-spec/spec/org.freedesktop.Telepathy.Verification.RemoteCertificate.html

  We had the following notes on the encryption spec:
    * Encryption spec needs to tell the client which information it should
      provide (what kind of certificates, which identity etc)..
    * Wjt mentions that this interface requires both the channel handler
      and the verification handler needs the certificates. Which seems
      unnecesarily complex and would require interaction between them
      (accessing the same certificate store etc).
    * Smcv suggest splitting the intention and the process. Which would mean
      that the encryption interface on the channel would just indicate the
      encryption state/level and the verification interface would handle
      fingerprints/passwords/certificates as needed. This means that if a
      clients wants to have an encrypted channel it's not required to
      reimplement a lot of the verification.
    * There is an open question about what kind of information should be
      available from the Encryption channel. A handler for a channel should be
      able to show the user how its channel is secured and why (used
      certificate X to verify identity Y etc). Given that with the split this
      is now part of the verification channel this isn't entirely obvious.
      Current concensus seems to be that we could have an EncryptionDetails
      property with contains this kind of information.
    * Open Question is what to do while still verifying/encrypting.. IOTW
      should the channel delay message delivery, not start an FT etc while the
      channel is still insecure. General consensus seems to be that we should
      be able to request a channel to be secure in which case it should indeed
      queue/fail/whatever anything before the channel is secured. If we're
      doing oppurtunistic encryption it's up to the CM to decide what to do, in
      general given that it's oppurtunistic it shouldn't be required to
      encryption everything as possible (there are no guarantees for the user
      in the oppurtunistic case, but they should still be able to know when
      encryption got turned on)

  On the SSL certificate validation
  * Question what to do when verifying a certificate at connect time and the
    handler disappears (crashes or whatever). A very rough proposal is to
    clarify things with the following ration.
    => If the SSL certificate channel gets closed unexpectedly (before either
      Accept or Reject is called) then the CM should treat it as a Reject if
      and only if the ContactCapabilities of clients show that there was in
      theory a handler for certificate verification. If there was no such
      handler in the ContactCapabilities then for backwards compatibility the
      CM should treat closing the channel as an Accept and fall back to its
      current behaviour wrt. certificates.

      This ensures that we're both backwards compatible and that we have a way
      of telling the CM that it should threat the verification channel as
      completely authoritive and thus closing the loophole where a certificate
      can cause itself to be accepted by causing the handler to crash.

  Sjoerd
-- 
You can never tell which way the train went by looking at the tracks.