Justin Karneges wrote:
> On Tuesday 13 January 2009 15:16:23 Peter Saint-Andre wrote:
>> According to my reading of RFC 4568, SDP Security Descriptions MUST NOT
>> be used unless the signalling channel (that's XMPP for us) can "provide
>> strong message authentication and packet-payload encryption, as well as
>> effective replay protection". Because we don't provide those services in
>> XMPP out of the box, I don't think we can securely use a=crypto (or our
>> XMLish flavor of a=crypto as currently described in XEP-0167). But we
>> might be able to use it if we negotiate XTLS (or some other e2e method)
>> first.
>
> I'm of the opinion that requiring e2e encryption to bootstrap secure oob
> sessions is perfectly acceptable. Relatedly, I'm of the opinion that having
> oob sessions inherit the security properties of XMPP helps avoid confusion.
>
> With the way XEP-167 is currently written, RTP is just as secure as your text
> chat. It's as simple as that. If both participants use the same server, and
> use TLS to that server, then RTP is protected within that domain, just as
> text chats are. If both participants use e2e encryption to protect the
> Jingle iq stanzas, then RTP is fully protected end-to-end.
It's just as secure, but I think the layering is wrong. IMHO we want to
pull the security negotiation out of the transport negotiation. At a
high level, this:
<iq>
<jingle>
<content>
<description/>
<transport/>
<security/>
</content>
</jingle>
</iq>
I'll post more detailed syntax and flows soon.
/psa
