On 09/16/2013 02:43 PM, Peter Saint-Andre wrote:
On 6/13/13 11:47 AM, Justin Karneges wrote:
On 06/13/2013 10:18 AM, Peter Saint-Andre wrote:
On 6/13/13 8:40 AM, Matt Miller wrote:
I don't necessarily have a problem with this as a
protocol-level diagnostic tool; it can help users (or rather,
the developers of the client the user interacts with) and
admins to troubleshoot. But the potential of abuse and
over-interpretation is extremely high.
Yes, that is true, and I too don't want people to read more into
the results than is justified. I will keep that very much in mind
as I work on the next revision.
What I'd like to see is an extra attribute on each incoming
stanza, indicating that it was received via a protected s2s
connection. Since the attribute would be per-stanza, it doesn't
have the race condition problem of the hop check.
[...]
Just one attribute is needed for this, stamped on by the receiving
server. Perhaps it could be a SHIM header.
Maybe this should be in a different spec than the hop check. I
just wanted to bring up the idea here since I figure it fits the
discussion. It would provide some amount of tangible security
without having to go full-on e2e.
Interesting. I definitely think that's worth pursuing, for the simple
reason that it can indeed be stamped by the receiving server (and I
can know whether my connection to the receiving server is encrypted).
To kick things off:
<header name='Security'>TLS</header>
We may also want a way to indicate that an outbound stanza should only
be delivered securely:
<header name='Security-Required'>TLS</header>
It occurs to me that we'll need a stream feature too, otherwise the
Security header could be spoofed and you have no way to know if the
Security-Required header will be honored.
S->C:
<stream:features>
<security-headers xmlns='urn:xmpp:security-headers'/>
</stream:features>
If the client does not receive the above stream feature, then it MUST
NOT process or provide stanza security headers.
Justin
