[Standards] secure s2s multiplexing
stpeter at stpeter.im
Mon May 4 19:32:00 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 4/30/09 7:46 AM, Philipp Hancke wrote:
> Alexey Melnikov wrote:
>>>> We see the following requirements:
> One prerequisite: when to multiplex? This might be possible both
> out-of-band (same ho:po via SRV) and in-band (subject contained in
Do you mean: when does an application decide that it would like to
request multiplexing for a given domain (rather than opening a new XML
>>>> * The multiplexing method must be backwards-compatible with
>>>> server-to-server connection methods.
>>>> * Each party to a server-to-server communication must be able to
>>>> determine if the other party supports multiplexing.
>>> unidirectional or bidirectional s2s for this? For bidi we need a
>>> reverse-stream:features feature anyway.
>> I think this should make the stream bidirectional.
> If it is bidirectional, who can add new domains? But that is probably
> digging too deep already :-)
I would think that either side can add domains (if adding domains has
>>>> * If the addition of a new domain to an existing domain-to-domain
>>>> stream fails, the existing stream must not be terminated.
>>> if the addition of a new domain to an existing stream fails, is it
>>> allowed to retry after x minutes?
>> Sure, why not.
> An alternative would be that a failure is considered permanent -
> blocking communication with that domain - and the remote end notifies
> the initiator if this situation changes.
That puts the burden on the receiver, which seems wrong.
>>>> * Multiplexing shall depend on presentation of a valid digital
>>>> certificate for the multiplexed domain.
>>>> * The certificate for a multiplexed domain should not be the same
>>>> (i.e., have the same subject) as a certificate that has previously been
>>>> accepted for the stream; however, if it is the same then it shall
>>>> replace the previous certificate with the same subject (e.g., to
>>>> a new certificate with a different expiry time).
>> PSA: I am not sure why this is a requirement. I think this is a part
>> of the solution you and Joe have in mind.
> Might be alternatively solved by removing the domain and re-adding it
> with a new certificate? Domain removal is missing from the list btw.
Yes, we need a way to remove a domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards