Pedro Melo wrote:
[...]
You have a valid certificate and private keys for all of the domains
you're hosting?
Yes, I have to if I want to host them. Same thing if you are a HTTPS
hosting company.
I know some people who will have a problem with that. Well... they will
probably continue to use _one_ certificate for all domains and
rely on no one caring about proper tls usage :-)
I don't know how you can reduce the number of certificates and keep the
same security properties of the protocol.
The request includes the pessoa.lit certificate? If not, how does
saramago.lit obtain the certificate to check the signature in step 3?
How does it work today? The certificate could be included in the request
or a out-of-band method could be used to obtain it. The security is not
based on how you get the other party certificate but on the CA that
signed it, right?
Yes. Which is why you can include the certificate in the request.
[...]
'random' keys are usually bad (replay attacks). The key should be - in
part - based on a challenge by xmpp.my.isp. Which makes this quite
similar to how dialback keys are generated... if you replace the key
validation part (4.3/4.4 in xep 220) with crypto instead of DNS mojo.
That is the idea, maybe I was not clear. The current challenge in a
It was clear. I just think it can be solved in a more backward
compatible way.
dialback scenario is also random, right? The point is that the initiator
chooses some key/string and uses that in the process.
In dialback, the challenge is the stream id sent by the receiving
server in example 2. The point is that it is not chosen by the
originating server.
In example 4 (xep-220), you would generate the 'key' as
{ 'saramago.lit', ' ', 'pessoa.lit', ' ', 'therandomchallenge'}
and then sign the resulting string with the pessoa.lit certificate.
Then you send a (modified) dialback over the connection:
<db:result from='pessoa.lit' to='saramago.lit'>
somemarker;base-64-signature;base64-certificate-of-saramago
</db:result>
If the remote server understands the crypto protocol and recognizes
the marker, it can reconstruct the message, verify the signature and
send the result (ex. 11).
If the remote server does not understand the crypto protocol, it
will treat the key as an opaque string and try to verify it using
dialback.
philipp
