[Jingle] Negotiation of SRTP in XEP-0167

Peter Saint-Andre stpeter at stpeter.im
Wed May 6 12:37:07 CDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/09 1:04 PM, Peter Saint-Andre wrote:
> On 4/22/09 2:54 PM, Justin Karneges wrote:
>> 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.
> 
> OK, I'll wordsmith it some more and re-post to the list. :)

Oops, I neglected to send this. How is the following text?

***

When the responder receives a session-initiate message containing an
<encryption/> element, the responder MUST do one of the following:

   1. Attempt to proceed with an encrypted session by including the
acceptable credentials (i.e., the relevant <crypto/> element) in its
session-accept message.
   2. Attempt to proceed with an unencrypted session by not including
any <crypto/> element in its session-accept message (it is up to the
initiator to reject this attempt if desired).
   3. Reject the initiator's offer by sending a session-terminate
message with a Jingle reason of <security-error/> (typically with an
RTP-specific condition of <invalid-crypto/>).

Which of these the responder does is a matter of personal security
policies or client configuration.

***

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoBysMACgkQNL8k5A2w/vwlvQCfWoJjqMj5L5fzNSWKajhifAkA
QbIAoM7tQoRHoIwPTG3bmqEmNW731GOE
=0yNu
-----END PGP SIGNATURE-----


More information about the Jingle mailing list