[Standards] Any protocol to request encrypted connections?
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.
>> 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...
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards