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

From: Philipp Hancke <[email-masked]>
Date: Wed, 31 Jul 2013 09:50:38 +0200

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.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 31 Jul 2013 08:18:50 +0000

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

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

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 < [email-masked] >
Cisco Systems, Inc.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 31 Jul 2013 10:01:20 +0100

On Wed, Jul 31, 2013 at 9:18 AM, Matt Miller (mamille2)
<[email-masked]>wrote:

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

If there is queasiness here it's misplaced. The case for abuse here is
predicated on the TLS handshake being the authorization, which it is not in
any SASL based protocol.

So in XMPP, we must already perform auth during the SASL exchange, and
during the <db:result/>, too.

If you have a protocol which conflates authentication and authorization, of
course, then the situation is different.