[Standards] Any protocol to request encrypted connections?
m at tthias.eu
Mon Feb 5 19:24:59 UTC 2007
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
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.
> Once clients support e2e all these issues will be resolved.
I understand that you like your XEP-0116 proposal and want to advertize
it, but there are situations where other protocols fit better.
More information about the Standards