On Jun 4, 2008, at 11:06 AM, Philipp Hancke wrote:
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 :-)
They can do that, but they shouldn't be surprised if sometime in the
future other servers stop talking to them.
Anyway, using a single certificate for all domains does not change
the protocol, but the verification of the certificate will fail on
the other side. What the other side does with the failure is a local
policy issue.
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.
Can or should?
[...]
'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.
Maybe I'm missing something obvious, but given that the stream needs
to be setup for the XMPP host and not the XMPP domain, I don't see
how we can be backwards compatible.
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.
yes, thats right. Yes, we could use that.
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.
Nice. But the initial stream still needs to be addressed to the XMPP
host name and not the XMPP domain. And you have to do that before
receiving the <features> from the remote domain. And this is not
compatible with the current system.
An alternative, we could also initiate the session as usual, from
pessoa.lit to saramago.lit, and announce this S2S multiplexing
feature, and it accepted, start the TLS handshake with the XMPP host
name. This would make it easier to deploy... Using this stream
feature, we can fallback to current s2s cleanly.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
