[Telepathy] Spec meeting about SSL and E2E Encryption

[Eitan Isaacson]

So.. yesterday we discussed further use-cases regarding encryption and
verification, and we thought of a few things which make it interesting.

In XTLS, after a shared secret is exchanged (SRP), the peers could
electively exchange certificates in a trusted manner, over a secure
channel, for verification during future encrypted sessions.

First off, we are departing from a simple certificate exchange, since
there is more than one method for verification (X.509, PGP, SRP, etc.),
the verification channel will need to have a property that signifies
it's verification method, preferably immutable. 

Also, s/Certificate/Identity in the verification API.

As for the apropo certificate exchange that occurs after SRP
verification, it differs from a TLS handshake exchange in that:
1. It is generally more trusted since it is done on top of a preceding
verification (SRP).
2. It is unrelated to a verification step, and thus accepting or
rejecting it has no meaning, the local client could choose to store it
for future use (or not), but the remote peer does not expect a reply.
3. A remote peer could choose to send more than one certificate that is
associated with the remote user.

For the above differences there needs to be a distinct way of exchanging
certificates outside of the standard verification path. We discussed a
few options, like a more versatile verification channel that can offer a
new 'trusted' certificate after an SRP exchange, and we also discussed a
new verification channel that would appear with a special state offering
a 'trusted' cert.

We ended up deciding on having a special channel type for this
certificate exchange that would partially implement the verification
interface, and would also implement the new Encryptable interface. When
a UI receives a cert over an encrypted channel, it will know from the
context that this is a relatively trusted cert that should be stored for
future secure sessions. See whiteboard sketch[1].

The 'Resource' property in the verification interface will move to the
ContactVerification type, as the ServerVerification does not need it
since the connection is inferred.  It will become an array so that more
than one resource could depend on the same verification, and it will be
renamed to something less confusing, 'Channels'?, 'TargetChannels'?

Open questions that we will probably discuss today:
* XTLS has a unique pre-verification step that consists of a fingerprint
exchange, it seems to be useful when one assumes that the certificates
involved are self-signed. This step also negotiates a verification
method. We must make sure we expose this step in our API.
* I forgot.. something about file transfer or redundant verifications?

1. http://people.collabora.co.uk/~eitan/spec_meeting1.jpg

On Tue, 2010-02-02 at 11:18 +0000, Sjoerd Simons wrote: 
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20100203/ffb53087/attachment.pgp