Peter Saint-Andre
06-05-2008, 08:15 PM
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/
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/