[Standards] Hop Check reconnects

[Dave Cridland]

On Fri Jun 15 10:50:52 2007, Ian Paterson wrote:
> 4. If my server's encrypted connections with my contact's server go 
> down and are replaced by unencrypted connections.

Reading through XEP-0219, I'm left wondering about a few things.

First off, Ian's point 4 above seems to be on the mark - we don't 
care if the hops were encrypted when we asked, we care if they're 
encrypted now.

Second, I'm not sure we normally care which links are not encrypted - 
we care if all of them are or not. The mechanism described in 
XEP-0219 might help an experienced user detirmine where the fault 
lay, and can be used to answer the question, but it's a lot of 
information to go through to answer a boolean question.

Thirdly, some of this information ought to be kept private. Something 
is nagging me that including the SASL mechanism used for 
authentication is probably not a good idea. I think there's probably 
more than the obvious case that knowing a hop uses no mutual 
authentication allows an attacker to scan for potential spoofing 
victims. I'm pretty sure that the network addresses should be 
omitted, too.

I had a quick chat with Ian about whether we might distribute 
encryption information in presence - such that servers implementing 
the extension would alter presence stanzas en-route to contain an 
overall indicator of the encryption state of the path - but not only 
does Ian disagree, but I've also realized that this doesn't solve the 
issue either. I think some mechanism for maintaining a path-state 
database is useful, though, and to my mind, adding this information 
to presence remains the obvious way to do it.

But we want to also know that a stanza sent to a specific destination 
will only go across encrypted links, and the only way I can see to do 
that would be to attach that requirement to the stanza itself, 
presuambly as an attribute on the stanza.

Neither fiddling with presence, nor new top-level stanza attributes, 
are particularly popular, of course, with good reason, but I think 
the need might justofy the cost in this instance.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade