On Thu, Jun 6, 2013 at 6:11 AM, Philipp Hancke <[email protected]>wrote:
> I've been thinking I'd like to resurrect the Hop Check proposal
>> (because after further reflection I think it would be useful, even if
>> not perfect):
>>
>
> for debugging/support? +1
>
>
I've not checked back to see whether I liked this or not before, so I don't
know whether now deciding it'd be a good thing would be an embarrassing
U-Turn or not...
But FWIW, when this was proposed, I think it was suggested as a "is my
end-to-end path secure?" - to which the answer is "not if you had to ask" -
rather than as a debugging protocol.
> [...]
>
> Before I post an updated version, does anyone have requests for data
>> they'd like to see included in the data format?
>>
>
> A bidi flag (for s2s) and the raw certificate data for both dialback and
> external auth. Probably also whether an SRV record was resolved or the A
> fallback is used.
>
> And keep in mind that most s2s connections still aren't bidi, see the list
> archives from 2007 for some discussion ;-)
>
1) I'd suggest for most things we just stuff features into the thing if
they've been used, maybe?
So for XEP-0138, we'd see something like:
<hop ...>
<compress xmlns='...'><zlib/></compress><!-- Oooh, we used zlib, yay! -->
</hop>
This'd hold for SASL auth, too:
<hop ...>
<sasl xmlns='...'>
<mechanism/>
</sasl>
</hop>
2) I know that having the certificate chain would also be useful, as well
as any reasoning for trusting it - or not trusting it, perhaps even more
important. There are many times I'd have dearly loved to have been able to
tell why a certificate wasn't trusted by the peer in ways that didn't
involve trying to parse other people's logs, so the reasoning here is more
useful that the certificate chain to me.
3) I'd also point out that while it'd be very useful to know how your
victim authenticates, having this as a mandatory feature seems like a
security issue. ("Oh, he authenticates using PLAIN without TLS, does he?
Oh, goody!")
4) Some links - S2S, for instance - have have different characteristics on
the return path than the forward path - XEP-0219 never addressed this. I've
a feeling this one came up at the time.
5) Currently, this protocol is framed such that each hop is mandated to ask
the next. It might be useful for this to be reframed as an end-to-end
protocol, so that Juliet asks her server, then Juliet asks Romeo's server,
then (possibly) Juliet asks Romeo.
So, erm, basically that's close to a complete rewrite, I think. :-)
Dave.
