[Standards] secure s2s multiplexing

Peter Saint-Andre stpeter at stpeter.im
Mon May 4 19:32:00 UTC 2009

Hash: SHA1

On 4/30/09 7:46 AM, Philipp Hancke wrote:
> Alexey Melnikov wrote:
> [snip]
>>>> 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
> certificate).

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
>>>> existing
>>>> 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
been negotiated).

>>>>     * 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
>>>> present
>>>> 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.


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list