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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
