[Standards] Any protocol to request encrypted connections?

Peter Saint-Andre stpeter at jabber.org
Mon Feb 5 19:31:35 UTC 2007

Matthias Wimmer wrote:
> Hi Ian!
> Ian Paterson schrieb:
>> Matthias Wimmer wrote:
>>>> Well, and even when we verify the identity of the destination 
>>>> server, we don't verify that the destination server is properly 
>>>> routing the stanza to the intended recipient. But I'd think that 
>>>> encrypted sessions would help here.
>>> I don't want to address the usecases of e2e by my question. One of 
>>> the use-cases I have in mind is more light-weight. I thought, that 
>>> you might e.g. operate a company server, that can be accessed from 
>>> the public internet as well. But some of the data you send to your 
>>> clients should only be sent out, if the connection to the client is 
>>> protected. It would be helpful if the sender of such 
>>> information/events could just pass an indication, that this data 
>>> should only be forwarded if the destination is verified.
>> Is it sufficient for all communications to be encrypted and for the 
>> receiver's server to verify that the receiver is who the receiver's 
>> server thinks the receiver is? If so, then that is accomplished simply 
>> by verifying that only encrypted, authenticated s2s will be used, and 
>> that the receiver logged in using an encrypted session and some form 
>> of non-anonymous auth.
> That's about what I talk about. But currently I cannot verify, that all 
> connections are encrypted and authenticated as the sender of a stanza. 
> (That was my initial question, if there is some protocol to query if all 
> connections are encrypted or better to request, that the stanza is only 
> forwarded on encrypted connections.

Not yet.

>> I know you're looking for something light-weight, but IMHO there isn't 
>> a simple solution, and you're totally dependant on none of the 
>> intermediaries having been compromised.
> Which might be okay in many situations. Especially if I am not able to 
> do e2e. E.g. because the destination's server does not want to allow e2e 
> encryption because it has to log all exchanged messages, because the 
> message is passing a gateway and we already start to forget RFC 3923, or 
> just because the client is connecting using a web-based interface.
> With TLS protected message forwarding all forwarding servers can fulfill 
> there logging requirements.
> With gateways a gateway can translate an indication, that an encrypted 
> channel has to be used, but it cannot gateway contents of a e2e 
> encrypted session.
> With the web-based interface the user cannot do e2e encryption without 
> giving away his keys ... but it is easily that web Jabber implementation 
> can check, that the user is connected using https and authenticated 
> using a client certificate.

Sure. So you want a kind of traceroute protocol that enables any entity 
in the path to know that the entire path is channel-encrypted. We've 
talked about such a thing many times, but haven't developed it yet. 
Maybe now is the time to work on it...


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070205/46b5d1de/attachment.bin>

More information about the Standards mailing list