[Jingle] Negotiation of SRTP in XEP-0167

Justin Karneges justin at affinix.com
Wed Apr 22 15:54:12 CDT 2009


On Wednesday 22 April 2009 13:40:34 Peter Saint-Andre wrote:
> On 4/22/09 11:34 AM, Paul Witty wrote:
> > XEP-0167 states:
> > "When the responder receives a session-initiate message containing an
> > <encryption/> element, the responder MUST either (1) accept the offer by
> > denoting one of the <crypto/> elements as acceptable (it does this by
> > mirroring that <crypto/> element in its session acceptance) or (2)
> > reject the offer by sending a session-terminate message with a Jingle
> > reason of <security-error/> (typically with an RTP-specific condition of
> > <invalid-crypto/>)."
> > However, this is only true when encryption is required, as otherwise it
> > also has the option of responding without any encryption.
>
> Good point. How is this?
>
> ***
>
> When the responder receives a session-initiate message containing an
> <encryption/> element with the 'required' attribute set to TRUE, the
> responder MUST either (1) accept the offer by denoting one of the
> <crypto/> elements as acceptable (it does this by mirroring that
> <crypto/> element in its session acceptance) or (2) reject the offer by
> sending a session-terminate message with a Jingle reason of
> <security-error/> (typically with an RTP-specific condition of
> <invalid-crypto/>).
>
> If the 'required' attribute is set to FALSE (this is the default),
> depending on personal security policies or client configuration the
> responder SHOULD accept the offer if possible, but MAY simply proceed
> without encryption.
>
> ***

I think this is still a bit confusing.  Even the bottom text, "responder 
SHOULD accept the offer if possible, but MAY simply proceed", is awkward 
(accept != proceed?).

How about rolling the it all into the first paragraph, and have three ways for 
the responder to act instead of just two.  1) accept with crypto, 2) accept 
without crypto, 3) don't accept.

-Justin


More information about the Jingle mailing list