Seriously delayed reply. :) On 06/15/2007 4:46 AM, Dave Cridland wrote: > 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.
Agreed. I hate to suggest this because people in the badattitude room will snicker at me (you know who you are!), but I suppose we could use PEP for this... :P > 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. The problem is, who answers this question? Is it something that I depend on my server to answer (if I trust it enough, blah blah blah)? I suppose so. > 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 think you're right. > 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. And, again, would my server add that on incoming presence it receives from people in my roster? > 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. Adding an extension to presence is not prima facie evil. So if I ask my server to track this information for a contact, it would add a signed extension to presence it receives from the contact telling me whether the full path is encrypted or not (based on information it has from the contact's server). /me ponders Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
