[Standards] Any protocol to request encrypted connections?

Mridul mridul at sun.com
Tue Feb 6 17:00:39 UTC 2007


Peter Saint-Andre wrote:
> Ralph Meijer wrote:
>> On Tue, 2007-02-06 at 16:19 +0000, Richard Dobson wrote:
>>>> why not jingle and use p2p udp with encryption of text?  but to be
>>>> honest sharing gpg keys between endpoints works well for me
>>> I have a feeling that wont work for what Matthias wants, I believe 
>>> he wants a method of ensuring the messages are delivered over 
>>> encrypted connections along the way but keeping the ability of 
>>> servers to be able to log those messages for compliance reasons, so 
>>> any form of e2e where the servers cannot decode the content is 
>>> pretty much out in this situation.
>>
>> Given that you would need to trust all entities in the path between
>> end-points, I expect a better (only) approach would be to only route e2e
>> encrypted traffic that can also be decrypted by the logging server, or
>> something.
>
> IMHO that's not really e2e encryption, then. :-)
>
> Given the existence of certain government regulations, I understand 
> the effective need to log communications at the server side, 
> especially in enterprise environments. Such organizations will 
> probably not allow their employees to use end-to-end encryption. But 
> they might want to ensure that a stanza is sent over encrypted 
> channels all along the routing path (c2s at local domain, s2s between 
> local domain and foreign domain, c2s at foreign domain). I think that 
> such organizations will probably open up interdomain federation only 
> with trusted partners and suppliers. So they will sign some kind of 
> business level agreement that involves promises of channel encryption 
> (either categorically or upon request). If channel encryption is not 
> required categorically, the question then becomes: how do you request 
> that a stanza must be delivered only over encrypted channels? Can you 
> request it for a given chat session, request it between two given 
> entities, etc.?
>
> Peter
>


So essentially user wants to ask server if route to contact is secure.
For now ...
1) user to server over tls.
2) server to remote server over tls. (if remote).
3) contact to server over tls.


1 can be answered by user's client, 2 can be answered by user's server, 
3 can be answered by a disco (new one?) to contact/remoteserver.
Not sure how this will work in case of intermediaries hosting contacts 
though.

Regards,
Mridul



More information about the Standards mailing list