Re: [POSH] Comments/questions on draft-miller-posh-00

["Matt Miller (mamille2)" <[e-mail]>]

On Jul 31, 2013, at 9:50 AM, Philipp Hancke <[e-mail]>
 wrote:

> Am 27.07.2013 19:22, schrieb Peter Saint-Andre:
> [...]
>>> Similarly, I can't see anything obviously wrong with letting the
>>> application handshake complete, then performing the POSH
>>> operations before deciding the application connection is not
>>> suitable and should be terminated before being used.  Is the MUST
>>> in this section mandating the order of operations necessary for
>>> some other reason?
>> 
>> As mentioned above, the MUST here is perhaps a bit silly because it's
>> so obvious. I think there is a better way to word it...
> 
> While implementing this I found another reason why this MUST doesn't work.
> 
> In XMPP we want DNA to have the ability to multiplex several domain pairs, with multiple remote domains.
> 
> However, at the time of the TLS handshake we only know a single remote domain (taken from the stream's from).
> 
> At any later time, the remote end may use this <db:result/> stuff to add another remote domain. This might trigger the POSH dance and clearly happens after the TLS handshake is done.
> 
> I would suggest removing this MUST.

These are all good points.

I will note that there is general queasiness with suspending disbelief on a connection, accepting the TLS handshake but then actually verifying  (and potentially failing) the connection because of TLS failings; not the least of which is the potential for abuse is very very great.  This also means that any error reporting that one might get from their TLS implementations for better error reporting is lost.

However, the multiplexing case is important for XMPP (not sure about others).  We need to allow for that to work.

I'll confer with my co-author, and we'll try to come up with some text that preserved the intent without being overly constricting.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.