Subject: [MMUSIC] Comments on draft-kaplan-mmusic-best-effort-srtp-01.txt

From: Flemming Andreasen <[email-masked]>
Date: Thu, 09 Nov 2006 11:05:28 -0500

Hi Hadriel and Francois

I've read the draft and have some comments on, which I've divided into 
general and detailed ones. The general ones are really the ones that 
require discussion at this point, whereas the detailed ones can be 
addressed at a later point (since several of them depend on the outcome 
of the general comments):

General comments:
=============
1) On scope and requirements, I think we definitely want to address 
profiles beside just RTP/AVP and RTP/SAVP. There is then also a question 
of what problem we want to solve beyond that. We have more than one 
draft right now with requirements (see 
draft-andreasen-mmusic-sdp-capability-negotiation-01.txt), and they are 
not consistent in their scope. We should ideally have only one, so more 
discussion is needed here. Which set of problems do we want to solve, 
and do we want to have different solutions to overlapping problems that 
only differ in the extent of their scope ?

2) I think the proposed solution of inferring rather than explicitly 
signaling the intended and supported profiles to be used is fraught with 
interoperability problems and in general will not work well as we get 
more and more profiles. Thus, the solution should have an explicit 
indication of the desired profiles to be used at a minimum. Related to 
that, I'm also somewhat concerned about the inclusion of attributes in a 
media description that may or may not have to be used, and it is up to 
the answerer to figure this out based on which profile he actually 
chooses (think "a=crypto" or "a=kmgmt" here for now). I'm also somewhat 
concerned about not actually listing the negotiated profile in the "m=" 
line. There are middle-box implementations (and MGCs for that matter) 
out there that simly strip unknown attributes and we encounter one of 
those boxes, the negotiation will succeed, but the media stream fail in 
case we use srtp.

Detailed comments:
=============
- Section 1, third paragraph
Should point out that if reattempting with RTP after failing with SRTP, 
then you run into HERFP issues.

- Section 1, fourth paragraph
Should point out, that if trying to upgrade from RTP to SRTP, this 
cannot be done until the initial O/A exchange has completed, which in 
turn may imply that early media and the initial "final" media may be 
insecure (unpopular alternative is to use security preconditions)

- Section 1, fifth paragraph
Another problem is that it's unclear (or at least not universally 
agreed) how the UAS tells the UAC that the reason for the rejection was 
lack of support for SRTP

- Section 1, third last paragraph
It's incorrect that the proposed technique is the only one that does not 
risk "breaking" any implementations. At least the simcap based approach 
has similar properties. ZRTP using  attributes would seem to have that 
property as well.

- Section 1, second last paragraph
I think the argument given is actually based on offer/answer (RFC 3264), 
which doesn't seem to prohibit the proposed behavior (but doesn't define 
it either). Also, to be clear, simcap as defined by RFC 3407 does not 
change any offer/answer semantics and hence any simcap capabilities 
included by themselves do not constitue alternative offers, only latent 
capabilities that could be used in subsequent O/A exchanges.

- Section 1, last paragraph
I don't believe it should be mandatory to use different payload types 
for RTP and SRTP under the given circumstance. If you use message 
integrity with SRTP, you can deduce whether SRTP or RTP is being used or 
not.

- Section 2, REQ-5
This seems to imply non-RTP based transports as well, which the proposed 
mechanism doesn't seem to address

- Section 2, REQ-7
I think we definitely want to have this as a requirement.

- Section 6
Would be better if the attribute actually indicated the supported 
profile(s) (e.g. "RTP/SAVP" instead of "srtp")
Should have rules for what to do with "byte-string"s received that are 
not understood.
Why limit the payload type range to 96-101 ?

-Section 7.1.1
It should not be a MUST level requirement to include payload type 
mapping if wishing to render received SRTP media before receiving the 
answer.

- Section 7.2
<quote>
   If it cannot support any of the offered crypto or key-mgmt
   attributes, however, it MUST treat the offer as if *no* crypto-
   attributes had been offered.  In other words, if the answerer's
   policy allows non-secure RTP, it can accept the offer as if it had
   been so.  If the answerer's local policy is to only allow SRTP media
   and not accept non-secure RTP, it MAY reject the offer.  This lets a
   key-mgmt-only offerer successfully negotiate non-secure RTP with a
   crypto-only answerer, and vice-versa.
</quote>
    I believe the last and second-last sentence should be swapped - the 
way it reads currently doesn't seem to make sense.

- Section 7.2.1
<quote>
   The answerer MUST answer such an offer using the actual/real payload
   types it is going to use for RTP or SRTP packets.  Therefore, if it
   selects to use SRTP and the offerer indicated payload type mappings
   in the srtp attribute, the answerer will answer using the srtp-
   specific payload type values in the m= media line of its answer.
</quote>
I'm not quite sure how to interpret this. You seem to require that the 
payload types in the "effective/accepted" offer and the answer are the 
same, where the effective offerered payload types are taken from the 
srtp attribute. This is clearly outside offer/answer, but as long as we 
have an explicit indication (and we do with the proposed "srtp" 
attribute), that should be ok. It is however inconsistent with 
offer/answer in another way, which is that RFC 3264 allows for 
asymmetric payload types. This mechanmis seems to preclude that and I 
think that needs to be rectified (there are important use cases for this 
related to H.323 interworking).

- Section 11
Another big security consideration is rendering of insecure RTP media 
received before answer. You don't know if the answer indicates use of 
SRTP or not, and if it did, you obviously shouldn't render such media. 
Security preconditions is one solution to that specific problem, but it 
obviously requires more than one O/A exchange.

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Randell Jesup <[email-masked]>
Date: Fri, 17 Nov 2006 22:46:03 -0500

Flemming Andreasen <[email-masked]> writes:
>I don't believe it should be mandatory to use different payload types for
>RTP and SRTP under the given circumstance. If you use message integrity
>with SRTP, you can deduce whether SRTP or RTP is being used or not.

Not all users of SRTP use an auth tag.  Some just are looking for privacy,
for which an auth tag isn't needed and it preserves bandwidth for payload.

>profile(s) (e.g. "RTP/SAVP" instead of "srtp")

That sounds good to me (without having the draft to reference while writing
this). 

>-Section 7.1.1
>It should not be a MUST level requirement to include payload type mapping
>if wishing to render received SRTP media before receiving the answer.

See my first answer.  Without a payload-type differentiation, you can't
know for sure if the incoming packets are RTP or SRTP.  For some codecs,
you might be able to infer if it's SRTP by length, UNLESS the sender is
using a null auth tag, and you may not know that until you get the answer.
Best to avoid the quicksand.

>received before answer. You don't know if the answer indicates use of SRTP
>or not, and if it did, you obviously shouldn't render such media. Security
>preconditions is one solution to that specific problem, but it obviously
>requires more than one O/A exchange.

This is worth mentioning, but it depends on the requirements of the
application/user.  If the caller is using best-effort encryption, there's
usually going to be an implicit assumption they're willing to have a
non-encrypted conversation, so they're probably willing to have an
early-media non-encrypted conversation - though it's probably VERY unlikely
for an answerer to respond with unencrypted early media and then encrypted
media.  So, if you get unencrypted early media, it's almost certain that
the answer will not select encryption.

The one exception I could see - in a system with send-keys (as opposed to
receive-keys, which for various reasons are not normally liked), an
answerer might send unencrypted media until it sees an ACK and then switch
to encrypted payloads, in order to avoid call-start clipping.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 20 Nov 2006 10:29:00 -0500

>Best to avoid the quicksand.
Agreed, however there is more than one way to skin that cat, so no need 
to choose one normatively.

>the answer will not select encryption.
Or somebody else is sending early media to you - that's the security 
issue with all of these mechanisms and it needs to be explained clearly. 
Jonathan will no doubt point out that ICE can help here (albeit not 
solve the issue completely), and that's probably worth mentioning too 
(again, as long as the limitations of that approach are explained).

-- Flemming